Incorrect dependencies after an npm install

[dbellizzi]

This is probably a TES specific one:

The way npm works is that if a top level dependency is unchanged (no version change), the sub dependencies are not updated. This causes problems in our bosco morning. For example, today bosco morning left me with a non working app-resource because it relies on refdata, which relies on module-resources-price-utils. Price-utils was updated, and refdata relies on latest, however refdata did not build a new version, and so bosco morning left the old price-utils in place, but started to rely on functionality that didn't exist.

Two ideas:

1. bosco morning could rm any dependency that relies on a "latest". But this doesn't address ones that use semver, as they wouldn't be updated either.
2. Jenkins could build a dependency graph and rebuild anyone that relies on a changed module as well. This would have rebuild refdata and then bosco morning would have updated it.

[cliftonc]

Bosco morning used to do a clean before install (e.g. wipe out node_modules), but it makes it very very slow.

The correct answer is to move to proper semantic versioning for your modules, and if refdata relies on price-utils, and price-utils is bumped a version, then you need to bump refdata too. Then everything updates.

Using latest is an anti-pattern, and also means that at the point you build you can't actually tell if the version you are using on Jenkins is the same one you just tested with locally.

[cliftonc]

I'll add to this, that for modules, we should configure jenkins so that it publishes to npm on a new tag (not sure if this is possible), but it is how travis does it: http://docs.travis-ci.com/user/deployment/npm/

[Josiah]

Using latest is an anti-pattern...

:+1: :+1: :+1: :+1: :+1: