Upgrade npm to version 5.0.3 (take 2)

[benjamn]

This PR takes the place of #8831, which was prematurely merged and closed by @benjamn.

This is a major update from npm 4.6.1, and should bring significant benefits in terms of speed and reproducibility of npm installs. Read the blog post for an introduction to those benefits.

To understand npm's new package-lock.json file format, I would highly recommend reading this documentation. Note especially that npm-shrinkwrap.json files are exactly the same as package-lock.json files, except that package-lock.json files cannot be published to npm.

For backwards compatibility, Meteor still works with npm-shrinkwrap.json files internally (for example, to manage Npm.depends-style dependencies), but that's perfectly fine because npm-shrinkwrap.json files have the same meaning as package-lock.json files. The distinction about publishing is moot because Meteor packages are not published to npm.

For application developers using meteor npm in their own apps, this update is a great opportunity to revisit your workflows to see if you can make better use of the new npm version. In particular, if you've been using yarn (or meteor yarn), you might consider switching back to meteor npm, since package-lock.json files are directly inspired by yarn.lock files.

Meteor remains completely agnostic about how you populate the node_modules directory in your application, so you shouldn't have to change your workflows at all if you don't want to. However, this new version of npm is a pretty big leap forward, so with any luck it will make your dependency management a little bit faster and more reliable.

[hwillson]

Déjà vu - looks good! 🙂

[abernix]

Lgtm! The tests that were failing before now pass—granted, it looks as if another unrelated (hot CSS push) will still fail.

[benjamn]

I have to admit I'm pretty baffled by the persistence of these test failures, as I can't imagine why the changes in this PR would affect the timing of those particular self-tests.

[hexagon6]

@benjamn duplicate extension test of circleci Build 4351 (container 1) seems to be failing because of this line:

=> Client modified -- refreshing% but expects

this line 'Modified -- restarting'

1| => Client modified -- refreshing%
compiler-plugins: compiler plugin caching - local plugin ...
... ok (54854 ms)
compiler-plugins: compiler plugins - duplicate extension ...
... fail!
... retrying (2 tries remaining) ...
... fail!
... retrying (1 try remaining) ...
... fail!
=> match-timeout at ../../../tools/tests/compiler-plugins.js:294

I suspect the output of the Sandbox has changed in the meantime? I was not able to test this so I'm guessing and would expect changing the test matching line

run.match('Modified -- restarting');

To

run.match('Client modified -- refreshing');

Might not fail the test. But I guess you might know better :-)

[hexagon6]

@benjamn @abernix While looking at the css hot code push test I saw this:

    // XXX: Remove me.  This shouldn't be needed, but sometimes
    // if we run too quickly on fast (or Linux?) machines, it looks
    // like there's a race and we see a weird state
utils.sleepMs(10000);

Might this be related to the failed tests we are seeing?

[benjamn]

@hexagon6 Thanks for looking into the test failures. As you can see, often the timing of tests, and the specific order of output, are the root causes of the failures (especially the sporadic ones). That utils.sleepMs(10000) call bothers me, too!