This fixes the bug where commands like `meteor add-platform ios` would
fail the first time with an error that cordova-lib could not be found,
even though we attempt to install the necessary packages if they have not
already been installed.
To make a very long story short, calling moduleDoesResolve before
installing dependencies like cordova-lib was causing Node.js to cache the
_absence_ of cordova-lib/package.json permanently in the new
packageJsonCache, which cannot be invalidated or cleared by user code:
f8f20892e9/lib/internal/modules/cjs/loader.js (L245-L255)
Although we could potentially propose a change to Node to allow the
packageJsonCache to be invalidated, a more immediate solution is simply to
avoid calling moduleDoesResolve when there's any chance the module will
not resolve. Because we still want to avoid repeatedly installing Cordova
dependencies every time we run a Cordova command, we instead check whether
the necessary dependencies are installed by examining the file system.
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`.
