Use npm shrinkwrap and travis caching

[diracdeltas]

fix #7820

• Submitted a ticket for my issue if one did not already exist.
• Used Github auto-closing keywords in the commit message.
• Added/updated tests for this change (for new code or code which already has tests).
• Ran git rebase -i to squash commits (if needed).

Test Plan:

1. automated tests should not fail with a lint error

[bsclifton]

Docs for reference (I've never used shrinkwrap- need to look more into it) - https://docs.npmjs.com/cli/shrinkwrap

This would make the updating processing interesting. I'm also curious if it'll work OK across platforms (Windows, Linux, macOS)

[cezaraugusto]

fyi I opened a PR to update standard@9 that could help as well: #7817 so repo/travis can share the same version

[cezaraugusto]

sorry just saw Yan comment on ref PR. I'm curious why Travis isn't matching repo's deps version.

[bsclifton]

@diracdeltas would you be able to run npm shrinkwrap --dev again against current master? (and commit/squash)

I think this PR solves the problem in a much more standard way than #8283. Sorry I had been hesitant to accept it- this would be a great one 😄

[NejcZdovc]

Left a comment in #8283 (comment). I think that we need this PR for travis caching, so that we can speed up our test's.

[diracdeltas]

updated shrinkwrap

[bsclifton]

++ 😄

[luixxiul]

Question: is it ok to run that everytime when I commit something to keep the dependencies up to date?

[bsclifton]

@luixxiul we'll want to pick and choose the times we update dependencies. Unless there is a good reason (need new version to get a feature, we're too out of date, etc) , we should stick with the version there. This is important to stabilize the codebase.

Any updates we do to libraries we use may require a small regression test to ensure the upgrade didn't break any functionality or introduce issues

[luixxiul]

@bsclifton thanks!