This should elegantly address the issues described in this comment:
https://github.com/meteor/meteor/pull/8327#issuecomment-280881830
I toyed with the possibility of turning package variables (both imports
from other packages and intercepted "global" variable assignments) into
properties on a shared namespace object, but that would have been a major
breaking change for existing package code, because it would have required
automatically rewriting variable references in package modules.
I made this code asynchronous at first to accommodate the asynchronous
cache API, but walking the graph needs to happen synchronously so that
near-simultaneous dynamic import(...)s do not interleave.
* Update help text to clarify the use of external npm commands
First attempt to improve the help text regarding the external npm commands that can be run directly with 'meteor'.
#8277
Further enhancements could include listing also the "current" available external commands by parsing a ls/dir command or 'meteor npm list -g -depth 0'. If they command is uninstalled between the call of 'meteor help' and 'meteor <external command>' we are not the ones to be blamed but the user instead :)
* Update 'external command' to 'npm command'
* Joining new suggestions and cleaning some redundancy
Included @abernix suggestions (with some variations) to include references to npm and node. Also clarified how to install a npm package and run it afterwards
* Typo
Changed to global context
* Reword description of "other" npm commands
These commands are similar to `node` and `npm`, but we didn't want
them to be confused with `npm command` commands.
* Avoid repetition of `meteor npm install --global`
In particular, if the "main" field of the package.json file cannot be
resolved, then the `resolved` variable will be "missing", which is a
truthy value that silently rejects property assignments. Ugh!
In particular, if the "main" field of the package.json file cannot be
resolved, then the `resolved` variable will be "missing", which is a
truthy value that silently rejects property assignments. Ugh!
* Added in Meteor.loggingOut() and related Blaze helpers.
* Switched loggingIn/loggingOut over to use ReactiveVar; More tests.
* Changed logginInOut helper name to loggingInOrOut.
We (@abernix and I) suspect the intermittent "died unexpectedly" failures
of `meteor --get-ready` on Circle CI are due to hitting their (low) limit
on the maximum number of open files.
Although optimistic caching speeds up rebuilds considerably, it doesn't do
much for initial builds, and it definitely keeps more files open.
Disabling it here seems worth a try.
@abernix Bumping the ecmascript version is apparently necessary if the
babel-compiler package has changed, presumably because ecmascript defines
a compiler plugin that uses babel-compiler. Unless the ecmascript version
has been bumped, babel-compiler changes won't appear to have any effect.
Although we thought the upgrade from `npm` 3.10.9 to 4.1.2 was worthwhile
and safe, this breaking change proved problematic:
https://github.com/npm/npm/blob/latest/CHANGELOG.md#no-more-partial-shrinkwraps-breaking
Specifically, if a Meteor package calls `Npm.depends` in a way that
disagrees with the contents of `.npm/package/npm-shrinkwrap.json` file,
Meteor will create a partial shrinkwrap file in order to install the
correct top-level npm dependencies, but transitive dependencies of the
package will no longer be installed.
This was fixed in Meteor 1.4.2.7 by reverting the upgrade of npm, but
Meteor 1.4.3.1 will keep npm@4.1.2 and fix the consequences.
The release-1.4.2.7 branch was begun from release-1.4.2.6, which has
fallen behind the master branch since release-1.4.3 landed.
To avoid conflicts when merging release-1.4.2.7 into master, I published
the official METEOR@1.4.2.7 release tag, then merged master into
release-1.4.2.7, and will soon (if the tests pass) merge release-1.4.2.7
back into master, putting master back in its 1.4.3 state, except with the
release-1.4.2.7 history included.
This reverts commit be0c8c3ee0.
Although we thought the upgrade from npm 3.10.9 to 4.1.2 was worthwhile
and safe, this breaking change proved problematic:
https://github.com/npm/npm/blob/latest/CHANGELOG.md#no-more-partial-shrinkwraps-breaking
Specifically, if a Meteor package uses `Npm.depends`, and does not yet
have an `.npm/package/npm-shrinkwrap.json` file, Meteor will create a
partial shrinkwrap file in order to install npm dependencies, but (with
the changes in npm@4) transitive dependencies of the package will no
longer be installed.
Upgrading npm to a new major version was probably too much of a change for
a 1.4.2.x release, anyway, so we're reverting it for 1.4.2.7.
In case you can't wait for 1.4.2.7, you can "fix" this problem for
previous versions of Meteor by running
meteor npm install --global npm@3.10.9
You can test that this downgrade worked by running
meteor npm version
