It makes very little difference between "npm run build"
and "npm run build --development" (both under a second),
since the gulp pipeline is smart enough to only uglify the new bits.
Creating different dist files with "--development"
is causing grief during pull requests, since most
devs will add the changed files without reviewing them.
It also means you can commit without stopping your "watch" npm task.
- Relaxed NodeJS dependency to 4.x
- Switch to NPM "dependencies" (rather than dev)
Provides consistency with framework, where these had previously
been broken out between "dependencies" and "devDependencies", which in turn caused issues with "npm shrinkwrap"
- Add npm-shrinkwrap.json: Consistent with framework approach
Using uber's wrapper library since it prevents npm shrinkwrap from failing on file generation,
as well as actually suceeding with an "npm install" once the file is present.
- Don't add comments to dist files via babelify
We've had some issues with different dependencies causing different results based on the environment,
which in turn causes unnecessary diffs - making our work harder to review.
Comments can be read through the ES6 source files, and through source maps when
generated through `npm run build --development`
- Make JS build tooling and naming consistent with framework
Uses https://github.com/uber/npm-shrinkwrap instead of the built-in "npm shrinkwrap" since it works more reliably.
Specifically, "npm install" doesn't fail depending on node_modules/ being installed in the local cache or not.
It also makes npm-shrinkwrap.json easier to diff by more consistently ordering its output between runs.
If you need any convincing that this is a problem, look at the over 400 issues related to "shrinkwrap"
in https://github.com/npm/npm/search?q=shrinkwrap&type=Issues&utf8=%E2%9C%93
CMSMain::getEditForm wasn't passing the $fields parameter to the parent. The the "Settings" fields we being replaced with the "Content" settings when requesting /admin/pages/settings/show/123345
Due to `"prefer-stable": true`, composer will use the 1.0.0 release which had a wrong dependency constraint (not limited to 3.x). It's too early to tag behat-extension 2.0.0 already in terms of semver - so we opt for installing the 2.x dev version instead.
