We haven't always updated this minimum version when we've changed the
Node.js version bundled with Meteor, which is fine because most deployment
strategies (including Galaxy) use the right version of Node.js
automatically. With Meteor 1.9 and Node.js 12.14.0, however, it seems
important that we make absolutely sure new Meteor apps are not getting run
in production with an end-of-life'd version of Node.js (v8).
Clearly we haven't remembered to bump this version for some time now,
which is too bad, because it could have provided a more helpful error for
developers using an older version of Node in their non-Galaxy deployment
environments: https://github.com/meteor/meteor/issues/9470
This adds a memoized helper function for detecting Emacs throughout the
CLI tool and automatically resorts to "ProgressDisplayStatus" mode when
Emacs is enabled.
In my tests with both Emacs 22 and 27, this nearly doubled performance
when using Meteor from within the Emacs shell (i.e. `M-x shell`).
Though this seems wasteful, it can happen if a SpringboardToLatestRelease
exception is thrown, and it definitely should spawn a new process rather
than returning normally from the springboard function.
Since we can't change the springboarding logic of existing Meteor
releases, this decision has to be made by the springboarded-to Meteor 1.6
release, and may result in a second springboarding.
Once Windows developers update to a 64-bit version of Meteor 1.6, they may
still wish to run apps using older versions of Meteor where only 32-bit
builds of meteor-tool are available. This commit makes that possible.
The syntax of these flags is the same as the equivalent Node.js options:
https://nodejs.org/en/docs/inspector/#command-line-options
When no port value is provided, the default is 9229.
Two notable differences:
* The flags affect the server process spawned by the parent build
process, rather than affecting the build process itself.
* The --inspect-brk flag causes the server process to pause just after
server code has loaded but before it begins to execute. This timing is
more useful than the Node.js --inspect-brk behavior, which is to pause
on the first instruction executed by the process, since that is too
early to set any useful breakpoints.
Implements https://github.com/meteor/meteor-feature-requests/issues/194.
By removing the `--allow-superuser` and `--unsafe-perm` arguments before springboarding, it prevents older versions of Meteor from objecting to its use. Catching it at the highest level should be sufficient to discourage root usage as intended in meteor/meteor#7821
Intended to fix... meteor/meteor#7959
This is important for `meteor npm`, since we don't parse or pass through
Meteor-specific command-line arguments when running `meteor npm`.
When METEOR_UNSAFE_PERM is set, its value is now propagated to any npm
commands via the NPM_CONFIG_UNSAFE_PERM variable.
Helps with #7959.
Follow-up to #7821.
This will make it easier to use tools like https://yarnpkg.com/ with the
right version of Node, etc.
With this commit, here's all you have to do:
meteor npm install -g yarnpkg
Then test that it works:
meteor yarn info
Note that any commands registered by Meteor itself will not be honored.
* Prevent running sudo meteor run it on Unix
Prevent running sudo meteor run it on Unix
Fix for all commands
remove empty line
Revert "Prevent running sudo meteor run it on Unix"
This reverts commit d2867561bb6fb1b259a59556628b56a64c677a0b.
improve PR
improve PR
improve PR
fix PR
* improve PR
* fix PR
* fix PR
* fix PR
Note that `export default` no longer modifies `module.exports`, but simply
defines `exports.default`, so these two import styles will work:
import DefaultExport from "./export-default-module.js"; // preferred
var DefaultExport = require("./export-default-module.js").default;
but this style will no longer work:
var DefaultExport = require("./export-default-module.js");
