Add draft profile to frontend build for faster builds

Description

During development, there's no need for compiling JavaScript with optimisations, or uglifying the code. We should add a draft profile which disables these optimisations.

We should also make sure it's easy to activate this draft profile from Maven when required (or to disable it when releasing).

Technical notes:

  • maven draft profile should not minify js files

  • maven draft profile build should not fail on eslint warning

  • maven draft profile should only be active when specified (i.e. default build should make a production-ready build)

Update:

  • After dev discussion, it appears better to have draft builds by default, so the implementation will go against the last point above.

  • Draft mode will be disabled with the 'release' profile.

Activity

Show:
Sean Flanigan
October 14, 2016, 3:39 AM

I do wonder about the last point.

We don't run all functional tests by default for mvn verify. Perhaps we should optimise mvn package for speed and only enable production-type features for specfically production-type builds.

In other words, perhaps we should instead default to draft mode, and enable Babel/GWT/Java compiler optimisations, minification, etc, only in prod mode.

David Mason
October 14, 2016, 4:39 AM

My thinking there is that if someone runs a build with no modifiers/profiles, they would expect to get the normal packaged software at the end of it. I consider that better behaviour than default draft mode. It only makes a difference for new developers, our team would be fine either way.

We can easily tweak that sort of thing later by defining which profiles are active by default, right?

Sean Flanigan
October 14, 2016, 5:40 AM

My thinking there is that if someone runs a build with no modifiers/profiles, they would expect to get the normal packaged software at the end of it. I consider that better behaviour than default draft mode. It only makes a difference for new developers, our team would be fine either way.

I used to think that, but my thinking has changed after too many years with Maven. Draft builds are needed much more frequently, so I think it makes sense for them to be the default. Perhaps users do expect normal packaged software, but perhaps they expect the build to run in a reasonable time. Naturally, it depends on the person. But if we optimise for speed, perhaps we will keep potential contributors long enough to actually make a contribution.

And as it is, we already disable checkstyle and various static analysis plugins by default.

Perhaps we should enable whatever checks and tests we can run quickly (including some of the static analysis if possible), and save compiler optimisations and slower tests until someone asks for them (eg with -Dprod -DallTests). We just need to make sure our official releases use that -Dprod option. The maven-release-plugin has a feature to ensure specified profiles are activated during the release process, although this doesn't apply to Brew builds out of the box.

However, I don't really care too much about the default, as long as we get the developer experience right.

If we reduce the number of Maven profiles we use, we could make it as easy as mvn -Dquick package to build zanata.war with some of the tests and checks, or mvn -Dquick verify to build and run some quick integration tests. Just so long as we make it really easy to find that information in our README (must keep it short). (quickbuild.sh is okay, but it's incredibly limited in its abilities compared the the mvn command, so I don't tend to use it.)

We can easily tweak that sort of thing later by defining which profiles are active by default, right?

Well, yes and no, because Maven is pretty clunky when it comes to profile activation. It's one of the hardest Maven shortcomings to work around.

If anyone ever runs mvn -PsomeOtherProfile someGoal to explicitly activate the profile someOtherProfile, only that profile will be active, because the -P option disables all other forms of profile activation - including the proposed draft profile and the production profile. In which case, neither profile will be used - just the main settings (and someOtherProfile of course).

David Mason
October 17, 2016, 2:35 AM

Great point, it makes sense to have the default build be whatever is best for external contributor experience. We have control of everything else so we can make sure we turn on appropriate profiles for those. That means the default profile should go for fast builds, with some of the quicker checks that will help avoid back-and-forth on PR reviews.

Sean Flanigan
November 4, 2016, 9:10 AM

There's some documentation for webpack's options here: https://webpack.github.io/docs/cli.html

Ready for Release

Assignee

David Mason

Reporter

Sean Flanigan

Labels

None

Tested Version/s

None

Story Points

1

Epic Link

Sprint

None

Fix versions

Priority

unspecified
Configure