* rename
* we don't need underscore to check whether an array is empty
* add types, resolve type issues
* remove unused markTop in run.js
* Make the type a little more consistent
* Tweak a check for an empty array
Co-Authored-By: Marcelo T Prado <marceloterreiroprado@gmail.com>
* Add separate SERVER_NODE_FLAGS envar
Since Meteor 0.5.3, Meteor allowed to pass node command line flags
to the server node process via the `NODE_OPTIONS` environment variable.
However, since Node version 8 / Meteor 1.6 this has become a default node
envar with the same behavior:
https://nodejs.org/api/cli.html#cli_node_options_options
The side effect is that this now also affects Meteor tool.
The command line parameters could already be set separately via the `TOOL_NODE_FLAGS` envar.
This is now also possible (again) for the server.
* Adds support to mongo options via Meteor settings
The options are in the `packages` key in the `mongo` key that is the package name. We should use the pattern every time we need a setting in a package.
SQLite has a worse-is-better philosophy about automatically converting
between different data types, such as strings and floating point numbers:
https://www.sqlite.org/quirks.html#flexible_typing
This means querying for the string "1.10" in a given column can return
rows where the column is actually the string "1.1", since SQLite imagines
you might be talking about the number 1.1, rather than the string you
actually requested.
This "feature" became a problem for Meteor after we published Meteor 1.10,
which caused SQLite to return multiple rows for the getReleaseVersion
query, including both Meteor 1.10 and Meteor 1.1 (which is ancient, from
March 2015).
While this behavior seems completely indefensible, the SQLite
documentation clearly does not consider it a bug, which forces us to work
around the consequences by double-checking the queried results with the
filterExactRows helper function.
This fixes the bug where commands like `meteor add-platform ios` would
fail the first time with an error that cordova-lib could not be found,
even though we attempt to install the necessary packages if they have not
already been installed.
To make a very long story short, calling moduleDoesResolve before
installing dependencies like cordova-lib was causing Node.js to cache the
_absence_ of cordova-lib/package.json permanently in the new
packageJsonCache, which cannot be invalidated or cleared by user code:
f8f20892e9/lib/internal/modules/cjs/loader.js (L245-L255)
Although we could potentially propose a change to Node to allow the
packageJsonCache to be invalidated, a more immediate solution is simply to
avoid calling moduleDoesResolve when there's any chance the module will
not resolve. Because we still want to avoid repeatedly installing Cordova
dependencies every time we run a Cordova command, we instead check whether
the necessary dependencies are installed by examining the file system.
I considered using a nonzero process.exit code, but I didn't want to run
any risk of reusing a meaningful code, and the accepted range of codes
unfortunately does not include parseInt("reload", 36), or 1657112629.
Should fix#10934.
updates are made to account for the following api changes
1.) raw is no longer used by xmlbuilder2
2.) element has been shortened to ele
3.) the create function signature/definition has changed compared to xmlbuilder
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.
Commit 646fa4e3eefixed#10547 by
restricting optimisticLookupPackageJson to package.json files with a
"name" property, which effectively skipped over intermediate package.json
files with additional properties.
However, in Node.js 12.16.0 (Meteor 1.9.1+), modules evaluated natively by
Node are considered ECMAScript modules if the closest package.json file
has "type": "module" (or has an .mjs file extension). This poses a problem
for the module.useNode() trick (see packages/modules-runtime/server.js),
because ESM modules cannot be imported using require.
For example, recent versions of the @babel/runtime package have a
@babel/runtime/helpers/esm/package.json file for the ESM versions of its
helpers (which specifies "type": "module"), but that package.json file
does not have a "name" property, because it is not the root package.json
file representing the entire @babel/runtime package.
I considered making the "name" restriction configurable, but that would
have fragmented the caching of optimisticLookupPackageJson. Instead, I
made it return an array of all potentially relevant package.json objects,
which can be safely cached.
This means that the caller has to iterate over the array, but there is
only one call site for this function (in tools/isobuild/package-source.js)
right now, so that wasn't too much work.
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.
Commit 646fa4e3eefixed#10547 by
restricting optimisticLookupPackageJson to package.json files with a
"name" property, which effectively skipped over intermediate package.json
files with additional properties.
However, in Node.js 12.16.0 (Meteor 1.9.1+), modules evaluated natively by
Node are considered ECMAScript modules if the closest package.json file
has "type": "module" (or has an .mjs file extension). This poses a problem
for the module.useNode() trick (see packages/modules-runtime/server.js),
because ESM modules cannot be imported using require.
For example, recent versions of the @babel/runtime package have a
@babel/runtime/helpers/esm/package.json file for the ESM versions of its
helpers (which specifies "type": "module"), but that package.json file
does not have a "name" property, because it is not the root package.json
file representing the entire @babel/runtime package.
I considered making the "name" restriction configurable, but that would
have fragmented the caching of optimisticLookupPackageJson. Instead, I
made it return an array of all potentially relevant package.json objects,
which can be safely cached.
This means that the caller has to iterate over the array, but there is
only one call site for this function (in tools/isobuild/package-source.js)
right now, so that wasn't too much work.
CircleCI tests will fail for this commit, since these changes do not
address the problem that the module.useNode() stub imports the ESM code
using require. I will fix the tests properly in a later commit.
