The move to eslint 1.x changes the way rules are managed, see:
http://eslint.org/docs/user-guide/migrating-to-1.0.0
There are slightly fewer rules enabled with "eslint:recommended" than
were by default before, but we'll enable more non-default rules later.
Normally grunt-cli (a wrapper around grunt to allow it to be easily run
from the command line) would be installed globally, so that it is on the
PATH. However to save having to do this on prod/Heroku/Travis, we
install it locally - and it will then be available via:
`./node_modules/.bin/grunt`
...or else via just `grunt`, if referenced inside a package.json scripts
section.
As of karma-jasmine 0.3.0, the jasmine library is not bundled with
karma-jasmine, and so jasmine-core has to be installed separately.
jasmine-jquery also has to be updated, since the old version was not
compatible. A duplicate jasmine-jquery file that was outside of the
tests vendor directory has also been removed.
To avoid Travis failing if new package authors don't follow semver and
break things in a point release.
This is effectively a no-op, compared to a clean install using the prior
package.json.
The karma package already comes with a wrapper script, so there's no
need to install another locally. The intended use for karma-cli is to
install it globally, which cannot be done from package.json.
The previous value of "^3.2.0" is equivalent to "4 > version >= 3.2.0".
We should pin to a specific version to stop deployments breaking if
a new release doesn't behave as expected. See:
https://nodesource.com/blog/semver-tilde-and-caret
We should also do the same for devDependencies, but let's do that in
another bug, since it doesn't affect production.
We were previously using '~' (which allows for N.N.*) and '^' (which
allows for N.*.*) for the grunt node package version numbers. This meant
that each person running grunt build could end up with different output,
since the versions were not pinned. Instead, all packages are now pinned
to a specific version - the latest currently available (which in many
cases is not far off the version someone running |npm install| in a
clean repo would have gotten anyway, due to the use of '^' and '~').
As part of merging the UI repo into this one, the following directory
moves were performed:
webapp/app/ -> ui/
webapp/test/ -> tests/ui/
webapp/config/ -> tests/ui/config/
webapp/scripts/ -> tests/ui/scripts/
webapp/scripts/web-server.js -> web-server.js
This means if |npm install foo --save-dev| is now used in the future,
the diff will be much clearer, since it won't also change the order of
existing entries.