* commit logs
* use the correct tools dir when using meteor warehouse dir env var
* remove logs
* remove logs
* run bin commands after springboarding
* revert change
* revert change
* fix npm command for checkout
* avoid to use unexisting tools path within a sandbox that describe a warehouse
---------
Co-authored-by: Nacho Codoñer <igcogi@gmail.com>
Bump the `source-map` version to fix the issue: https://github.com/mozilla/source-map/issues/454.
We are not updating the NPM version because there is an breaking change with the `npm config set python` which we use with `node-gyp`.
This commit also removes the fork of `pacote` that Meteor used to use - hopefully, the issues that were fixed with our patch are already fixed on upstream.
- 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
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.
