Lock npm versions

[NejcZdovc]

Describe the issue you encountered:
Lock all npm packages to the specific version, so that we are all working on the same dependencies.

In this issue I am NOT updating anything to the mayor version, just settings values that we get now if we run npm i

We should update all dependencies with every release.
cc @bbondy @alexwykoff @bsclifton

[luixxiul]

We should update all dependencies with every release.

Let's consider using greenkeeper #1701

[NejcZdovc]

@luixxiul I like it, let me try it out

[bsclifton]

an Alternative we can consider too: shrinkwrap

@diracdeltas put together PR #7795 which I didn't feel comfortable accepting (yet) because I'm unfamiliar with shrinkwrap / am not sure how the update process would look like

[NejcZdovc]

@bsclifton personally I prefer automated things, so this greenkeeper will force us to be up to date 😃

[alexwykoff]

Greenkeeper will only make sense after we have a consistently passing CI otherwise things will 'magically break' and you will be hunting for a long time to figure out why.

[diracdeltas]

I think we should lock NPM versions, but I don't think we should be updating the lock to the latest version of every package with every commit/PR. We tried doing that for brave/sync (which has far fewer dependencies) and it soon became difficult to track down what bugs were due to a dependency update.

It might be ok updating the lockfile once per release, as long as there is enough time for testers to catch bugs that are due to dependency updates.

If we lock down versions with shrinkwrap or Yarn, I can re-enable Travis dependency caching.

[luixxiul]

It might be ok updating the lockfile once per release, as long as there is enough time for testers to catch bugs that are due to dependency updates.

I'm thinking about the possibility of updating packages based on the release channels.

eg

• Nightly/Alpha -> major.minor.maintenance
• Beta -> minor.maintenance
• Release -> only .maintenance

It could only cause chaos, though. Just my idea.

[luixxiul]

otherwise we could update deprecated packages at least.

[bsclifton]

@NejcZdovc what do you think about accepting #7795 in lieu of this PR?

[NejcZdovc]

@bsclifton @diracdeltas correct me if I am wrong, but doesn't this only apply when travis or our build pipe is using npm. When I as developer clone browser-laptop and run npm i shrinkwrap is not used and we will have different versions of packages. I think that we need to use both PR's. My is meant for developers, so that we have all exactly the same versions and shrinkwrap is needed for travis. If I misunderstood shrinkwrap and when you run npm i shrinkwrap will be used and not package.json then my PR is not needed.

cc @bbondy

[diracdeltas]

@NejcZdovc my understanding based on https://docs.npmjs.com/cli/shrinkwrap is that shrinkwrap is used for npm install.

[bsclifton]

Closing in favor of #7795

[bsclifton]

@diracdeltas that is correct- npm install will respect shrinkwrap 😄

[luixxiul]

On the latest npm, the file package-lock.json is produced after npm i. Should we add the file to .gitignore?

[NejcZdovc]

We can for now, but as soon travis supports npm 5 we will use it for caching

[bbondy]

Re-opening for npm5

[bsclifton]

We've been using the lock files and these have worked out great 😄 👍