Node packages that are intended to be called from the command line can
request that symlinks be added to `node_modules/.bin/` as part of their
installation. When `npm/yarn run` is used, it automatically adds that
directory to the PATH, so commands listed in `scripts` in `package.json`
can normally be specified without the full filepath.
However when npm/yarn is used inside a Linux Vagrant instance running on
a Windows host, even though the guest OS supports symlinks, errors will
occur if symlinks are created in a directory that is shared with the
host using Virtualbox shared folders.
In this case, the workaround is to prevent the creation of symlinks
using `--no-bin-links`. However unfortunately instead of having a
sensible fallback (eg a shell script that acts like a symlink) instead
no files are created in `node_modules/.bin/` at all.
As such, we have to use full paths in `package.json` after all.
For the same reason as the previous commit.
Ideally we'd remove the grunt abstraction entirely and call eslint from
the `lint` command, but we might as well save that to the Neutrino PR.
Routing commands via npm/yarn is preferred, since it avoids
having to do global installs of grunt-cli, which simplifies contributor
setup, and means less effort when we switch to Yarn (since it requires
manual PATH setup for globally installed packages).
Vagrant uses the latest 7.x.x release, which is now 7.7.2. To reduce
differences between environments whilst the Neutrino/webpack work is
stabilised, it makes sense to update Heroku/Travis again too.
Introduces the ngreact-test-utils npm package to supply reusable
compile() and simulate() functions for testing ngreact components. This
requires browserify, which is now applied to tests in
tests/ui/unit/react only.
This is required because the older version of grunt-angular-templates
was hanging with component templates. In order to upgrade everything it
was also necessary to switch from grunt-cache-busting, which is no longer
maintained, to grunt-cache-bust, which is.
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.