On the server, Meteor attempts to avoid bundling node_modules code by
replacing entry point modules with a stub that calls module.useNode() (see
packages/modules-runtime/server.js). This trick allows evaluating server
node_modules natively in Node.js, faithfully preserving all Node-specific
behaviors, such as module.id being an absolute file system path, the
__dirname and __filename variables, the ability to import binary .node
modules, and so on.
However, starting in Node.js 12.16.0 (Meteor 1.9.1+), modules evaluated
natively by Node are considered ECMAScript modules (ESM) if the closest
package.json file has "type": "module" (or has an .mjs file extension).
This poses a problem for the module.useNode() trick, because ESM modules
cannot be imported synchronously using require (which is currently how
module.useNode() works).
To work around this new error, this commit checks package.json for "type":
"module" in ImportScanner#shouldUseNode to determine whether it's safe to
use the module.useNode() trick.
The good news is that ESM modules don't have access to nearly as many
Node.js-specific quirks: no module, require, or exports variables; no
__dirname, no __filename; no ability to import JSON or other non-ESM file
types (at least right now). So it seems somewhat less important for ESM
code (compared to CommonJS code) to bail out into native Node.js execution
using module.useNode(). In other words, bundling server code should not
affect its execution in nearly as many cases, if that code is ESM rather
than legacy CommonJS.
If this good news turns out to be overly optimistic, we can consider using
a different kind of bailout stub that's capable of importing ESM using
dynamic import(). For now, making sure we avoid bailing out for ESM code
like @babel/runtime/helpers/esm/* is the priority.
With Node.js 8.x nearing end-of-life status at the end of this year, and
Node.js 12 now in LTS, we think it makes sense to finalize Meteor 1.9
sooner rather than later, and continue working to take advantage of all
the great features of Node 12 in future 1.9.x releases.
As usual, the meaning of "release candidate" is that we can still fix bugs
before the final release, but there will be no new features added.
When we run 'meteor test-packages' as part of our Circle CI test rotation,
we happen to be testing the Meteor `jquery` package along with all of our
other packages, so it has a chance to define `window.jQuery` globally, so
everything seems to work.
However, if you run `test-packages` with a subset of packages that does
not include or depend on `jquery`, there will be errors in the browser
console about `jQuery` not being defined, because the `test-in-browser`
package depends on `blaze`, which implicitly depends on `jquery`.
Although the Meteor jquery package is no long a core package (and thus is
not tied to the Meteor release), it seems like a good idea to nudge folks
towards installing jquery from npm, instead of relying on the very old
version (1.12.1) residing in meteor/packages/non-core/jquery/jquery.js.
Closes#10289.
Adding native `bcrypt` to a project may require build tools be available on the system. This commit adds a note about that, and a link to the node-gyp documentation that best explains which tools to install. For more details, see this issue: https://github.com/meteor/meteor/issues/10113
Should help with #10795.
Also updating the meteor-babel and @babel/runtime versions in the dev
bundle, though there is no need to rebuild the dev bundle immediately.
* remove jquery and deprecated bootstrap dependency in test-in-browser
Another step towards https://github.com/meteor/meteor/pull/10498
The direct jquery dependency was not necessary as far as I can tell. There was a second indirect dependency through the deprecated bootstrap package from which we only need the css.
So I replaced that one with bootstrap 4 css from npm
* Improve styling for test-in-browser
