This is a follow-up to b4a68e99c1, which
allowed obtaining a simplified list of build architectures (without
web.browser.legacy) by calling isopack.buildArchitectures(true), which was
helpful for matching existing builds of packages that were published
before the web.browser.legacy architecture was introduced in Meteor 1.7.
Now that some packages have been published with the web.browser.legacy
architecture as part of the Meteor 1.7 release, it's important to try
matching the full unsimplified list of architectures, while still falling
back to the simplified list for other packages.
I'm not entirely sure this will work, but the alternative is having to
bump the patch version of every core package, so I'd like to see if this
simplification works first.
Fixes an issue preventing the installation of scoped Cordova
packages. For example,
`meteor add cordova:@somescope/some-cordova-plugin@1.0.0`
will now work properly.
Fixes https://github.com/meteor/meteor/issues/7336.
It's still possible to publish packages for different platforms by using
the `meteor publish-for-arch` command, though it's become increasingly
difficult to offer compatible versions for every circumstance due to the
wide matrix of Node.js ABI versions. This makes it unlikely that
a package built on the build farm will be appropriate for the
application which the package is consumed by, substantially reducing the
overall value of rather expensive infrastructure.
Since Meteor 1.4, and as part of the jump from Node 0.10 to Node 4,
Meteor introduced the capability to compile binary dependencies at the
time that a package is installed. Additionally, many Node.js packages
are already pre-compiled in a much more effective and wide-spread nature
for the entire JavaScript ecosystem using tools like `node-pre-gyp`.
cc @benjamn.
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.
Tiny fix for an old issue where the console output would get corrupted when running `meteor admin set-unmigrated` or `meteor admin change-homepage` due to missing newline on `rawInfo` command.
Fixesmeteor/meteor#4054
Tests were broken by the new dependency on the babel-runtime npm
package, but fortunately all those tests run `meteor --prepare-app`
whenever an app is created by a self-test, so this change should fix
most of the breakages.
See #7495. Still some decisions to be made:
- Should we make --all-packages the default?
- How should we deal with *new* indirect dependencies?
- Should we do anything about underpinning indirect dependencies when updating?
See https://github.com/meteor/meteor/pull/5562/files for a discussion. Basically Cordova doesn't really support
a) Urls with @'s in them
b) Urls that don't point to fixed commits.
As this branch allows both of the above (and our NPM support does reasonably handle a+b), we split the way we handle cordova + npm URLs a little.
Exclude core packages (whose versions are pinned) from being printed
when we say:
"Newer versions of the following indirect dependencies are available".
Cordova plugin IDs have changed as part of moving to npm. We convert
old plugin IDs to new IDs in the 1.2.0-cordova-changes upgrader, when
adding plugins, and when preparing for build.
