The changes made in #9213 were seemingly innocent, but when merging
I missed the fact that the 'cordova-lib' package bump was done to a new
entry on the 'dev bundle', rather than on the
`CORDOVA_DEV_BUNDLE_VERSIONS` in tools/cordova/index.js which, as of
meteor/meteor#8976, is responsible for auto-installing Cordova when it
is used rather than including it in the pre-packaged 'dev bundle'.
That mistake was fixed with 958c44ff1b and
d6adc1b3a9, but not before it caused the
Cordova tests to falsely pass on the PR since it was functionally still
testing the previous version of Cordova, 7.0.0.
Unfortunately, one of the changes in the 7.1.0 was the deprecation of an
API we use within Meteor: the `raw` API on `cordova_lib`. Luckily, as
seen on the following commit, that change was merely a re-organizational
commit and still provides us access to that API by simply removing
the `raw.` segment and accessing the various methods directly:
90b6857f4d
Never saw that deprecation message, but we certainly saw the failure in
CI: https://circleci.com/gh/meteor/meteor/10412.
With any luck, this commit/PR will fix the problem.
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.
I think I just typo-ed that patch version right before I committed it.
It certainly should have been 7.1.0. :(
Ref: https://github.com/meteor/meteor/pull/9213
cc @skirunman.
While 'cordova-lib' used to live in 'dev-bundle-tool-package.js' where
it was pre-bundled into the "dev bundle", that is no longer the case.
It is now automatically installed, on demand, when Cordova is used.
This follows up on meteor/meteor#9213, which added it back to the
'dev-bundle-tool-package.js' and updates it in the new location.
Ref: https://github.com/meteor/meteor/pull/9213
Ref: 073f2410a6
cc @skirunman.
Several years ago, before all major browsers supported source maps, we
felt it was important to provide line number information in generated
files using end-of-line comments like "// 123\n".
Adding all these comments was always slower than leaving the code
unmodified, and recently they have begun interacting badly with certain
newer ECMAScript syntax, such as multi-line template strings (#9160).
Since source maps are well supported in most browsers that developers are
likely to be using for development, and the line number comments are now
causing substantive problems beyond the performance cost, I think it's
time we stopped using them once and for all.
Fixes#9160.
The `installPath` property was always essentially an absolute module
identifier that was simply missing the leading '/' character, so this
commit acknowledges that role by renaming the property to `absModuleId`
and adding the leading slash.
This was dangerous because source is often a path relative to the old
target file, whereas files.stat was interpreting source as a path relative
to process.cwd().
Fixes#9203.
A while back, for performance reasons, we disabled yielding for all
files.* operations unless METEOR_DISABLE_FS_FIBERS was set to false.
This was safe for almost all files.* operations, because most of them have
a synchronous fs.*Sync version available.
For a more complicated operation like files.rm_recursive, however, there
is no synchronous or asynchronous counterpart in the fs.* namespace, so
the safety of disabling fibers is not guaranteed.
Lately, files.rm_recursive has become a major source of uncaught ENOTEMPTY
errors on Windows, because rimraf.sync fails with that error, and we don't
give files.rm_recursive_async a chance to delete the directory in a more
persistent, forgiving manner.
The only reason we haven't been falling back to files.rm_recursive_async
is that YIELD_ALLOWED is false by default, so canYield() returns false.
This commit distinguishes between canYield() and mayYield(), and uses
canYield() in files.rm_recursive to determine whether it is technically
safe to yield, regardless of YIELD_ALLOWED.
Anyone who ever asked "Can I go to the bathroom?" in elementary school,
only to be mercilessly rebuked with "I don't know, CAN YOU?" should
understand the difference between these two functions.
This means running `meteor update` on Windows with an existing (pre-1.6)
installation of Meteor will install a 32-bit version of Meteor 1.6, even
if the underlying machine architecture could handle a 64-bit version.
To get a native 64-bit version of Meteor, Windows developers should
reinstall Meteor 1.6 from scratch using the new and improved Windows
installer (👋 @abernix), rather than running `meteor update`.
If we really want to make `meteor update` just work ✨, we can
revisit this change in Meteor 1.6.1.
Whatever benefits this may have had, a general purpose function like
files.extractTarGz is definitely not the place for such an aggressive
safety measure, and the performance penalty is significant, especially on
Windows.
