This was causing problems with `npm@5`, but realistically it may not be
be necessary anymore since `npm@5` has a much smarter global,
self-healing `cacache`.
This Cordova `ensureDevBundleDependencies` function will utilize a another
method called `ensureDependencies` which checks to see if a module can be
resolved by the tool. If it cannot be resolved, it will install it using the
`installNpmModule` facilities of `meteor-npm.js` in the same way as other npm
packages within packages, except with the destination as the `dev_bundle`.
This commit also adds a couple of previously not explicitly installed npm
modules which Meteor requires directly: `cordova-registry-mapper` and
`cordova-common`. Both of these were previously relying on npm package hoisting
which previously occurred during the installation of `cordova-lib` in the dev
bundle which happened under the supervision of a `package.json` file (which is
later purged).
When `cordova-lib` is installed directly, without a package.json, the
aforementioned packages are not hoisted to the top level, but instead reside
inside `cordova-lib`. This is less than ideal since we're relying on the API
of an indirect dependency of `cordova-lib`.
This will enable the possibility of deferring the installation of the Cordova
modules (e.g. `cordova-lib`, `cordova-common`) until a time deemed appropriate.
This is the feature that excites me most about Meteor 1.6, hands down.
Benefits include:
* Works with `meteor test[-packages] --debug-port 9229` (for tests), as
well as just `meteor debug` (for apps).
* The application process waits patiently for the debugger to attach, so
you don't have to race to open the debugger.
* The application process pauses at a location just after all server code
has been evaluated, but before any code starts executing, giving you a
chance to set reliable breakpoints anywhere in server code. This is much
better than using the `node --inspect-brk` flag, since that stops too
soon to set any useful breakpoints.
* The application server runs at full speed, so you don't have to wait
forever to hit that all-important breakpoint, and you don't lose nearly
as much time if you accidentally continue past the line of code where
the trouble is occurring.
* Even if your application is stuck in an infinite loop, you can still
attach the debugger, pause execution, and debug the loop.
* No more `node-inspector`! Instead, you can now debug your server code in
native Chrome DevTools, or several other high-quality inspector clients,
such as VS Code or WebStorm (seriously, check out the documentation:
https://nodejs.org/en/docs/inspector/#inspector-tools-clients). The list
of debuggable processes can be found at the URL chrome://inspect.
* Realistic performance and memory profiling is now possible via the
familiar DevTools interface.
* I highly recommend this Chrome extension that automatically (re)connects
to any open inspector sockets, so you don't have to keep manually
(re)attaching the debugger: http://june07.com/nim
* The implementation of `meteor debug` no longer has to proxy multiple
private/public debugger ports. Look at all that deleted code!
This new inspector is so much better than the old `node-inspector` that
I've been using the release-1.6 branch to debug problems in Meteor 1.5,
despite the risks of using Node 8, because those risks are so far
outweighed by the quality of the new debugging experience.
That said, the experience isn't perfect (yet). I welcome your feedback on
the Meteor 1.6 PR: https://github.com/meteor/meteor/pull/8728
* 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`
Package version unpinning (#7084) removed all exact package@=version
constraints derived from the current release.
As we discovered with Meteor 1.4.2.4 (#8306), this meant releases no
longer had any power to enforce package upgrades, which is why the
follow-up Meteor 1.4.2.5 release (#8311) was necessary.
This commit has the same effect as putting package@version in your
.meteor/packages file for every local/core package that your app uses.
