We now check `package.json` in order to help make an educated decision
as to whether or not a package has binary dependencies which need to be
rebuilt. In some cases, such as the `npmconf` npm which is included
as a dependency of `flow-router, the `package.json` is invalid (i.e.
empty), and we should silently permit this.
Fixesmeteor/meteor#8427
This is a developer experience (DX) change.
In production, the `METEOR_SETTINGS` environment variable is used to
pass parameters which will be available in the `Meteor.settings` within
the app. However, `METEOR_SETTINGS` is ignored when using the
`meteor-tool` itself as in development, environment variables are
often less desirable. Additionally, there would be no reactivity when
changing settings was necessary, instead requiring that the `meteor`
tool be restarted entirely.
On more than one occasion, developers have been confused as to why the
`METEOR_SETTINGS` are not respected in development. To make it more
clear when this is attempted (and clarify that they will _not_ be used),
provide the a clear warning before ignoring the `METEOR_SETTINGS`
variable.
Aims to avoid meteor/meteor#8455.
* Update generated README
- Update node version in generated README file by bundler, according
to version from `.node_version.txt` file
* Use `process.version`
- Minor file linting, one missed semicolon, one unnecessary semicolon
* 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!
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.
Inspired by analysis from @danstiner:
https://github.com/meteor/meteor/issues/8225#issuecomment-275044900Fixes#8225, as well as the tests I added in 672c4f338a.
I changed the name of the .meteor-portable file to .meteor-portable-1.json
in order to invalidate previous .meteor-portable files. This naming scheme
will be more sustainable, because we can keep incrementing the version
number whenever we change this logic.
Implicit empty stub CSS modules added in addStylesheet in
compiler-plugin.js were being overwritten with actual CSS module code,
thanks to logic intended to support replacing package.json stubs with
their actual contents.
The meaning of "implicit" is somewhat overloaded: for package.json
modules, it means the module is a minimal stub (just the "name",
"version", and "main"/"browser" fields) that should be replaced if ever
explicitly imported. For empty stub CSS modules, it means the module
should yield to any actual modules added via addJavaScript.
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.
Previously, when building a JavaScript bundle for the client, if a
package.json file had a string-valued "browser" field, we would replace
the value of the "main" field of the bundled package.json module with the
value of the "browser" field. This trick was important because it allowed
an npm package to have a different entry point on the client than it had
on the server.
However, that approach became inconsistent if the package.json file was
also explicitly imported as a module, because the package.json stub used
for module resolution prevented the real contents of package.json from
getting bundled, and disagreed with the original package.json module about
the value of the "main" field.
To resolve that inconsistency, it seems better to avoid modifying the
"main" field of package.json modules, and instead rely on the runtime
module system to make sense of the "browser" field, regardless of whether
the package.json module is a stub used only for module resolution or
contains the full contents of the original package.json file.
The ability to understand "browser" fields of package.json modules was
introduced in install@0.8.3:
377d1a3b51
This is potentially a backwards-incompatible change for developers using
this version of `ImportScanner` and `Resolver` who have not yet upgraded
their `modules-runtime` package to at least version 0.7.8. The solution is
to upgrade `modules-runtime`, though it would be nice to enforce that
better somehow.
