- Update node version to 18.12.1
- Update npm version to 7.24.2 (last before 8)
- Update commands to use async
---
NPM 8 break changes
Error: The programmatic API was removed in npm v8.0.0
https://github.com/npm/cli/blob/latest/index.js
Implements feature request #406 by allowing to type a --json option
and let the tree output be in JSON format. The entries consist of
the package name as key and either String value (version number +
top-level or expanded-above) or an Object with the following
properties:
- version (String) - always
- local (Boolean) - only if true when package is built from source
- weak (Boolean) - only if true
- newerVersion (String) - only if exists
- dependencies (Object) - only if > 0 and not all weak
In order to also support a more detailed output, there is a --details
option. If it's active, the following properties are added, too:
- earliestCompatibleVersion (String) - always
- debugOnly (Boolean) - only if true
- prodOnly (Boolean) - only if true
- testOnly (Boolean) - only if true
- containsPlugins (Boolean) - only if true
- lastUpdated (Date-String) - always
- published (Date-String) - always
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.
