Due to the instability of atom's package api, we have the CI process
failing to install some packages. This failure is random and there is no
way to have consistent results.
According to https://www.electronjs.org/blog/apple-silicon,
if arm64 is going to be supported, `electron-packager` should be at least
`15.1.0`
Running npm install seemed to update a bunch of other things
Also language-ruby keeps reverting to 0.72, this seems to fix that.
This version has all the known security patches in v3.x,
and is meanwhile the recommended version to use from CommonJS
(NodeJS-style) modules, as opposed to ESM.
Atom's build and CI scripts are all CommonJS as far as I know,
so we should basically stay on node-fetch v2.x.
This fixes the currently broken "Bump dependencies" job in Nightly CI.
Effectively reverts ad1318e3fb,
AKA https://github.com/atom/atom/pull/23506,
albeit with a more up-to-date patch version of node-fetch v2.x.
We have defaulted to using npm that installed as part of the script
dependancies. This is to increase predictability on what version of npm
was used to install atom dependencies
"Node 10.12 or newer" has been a hard requirement since this PR:
https://github.com/atom/atom/pull/20879,
due to newer versions of electron-chromedriver and electron-mksnapshot
relying on extract-zip@2 as an indirect dependency.
(extract-zip@2 requires Node 10.12 or newer for its recursive mkdir.
Using extract-zip@2 with Node older than 10.12 results in errors.
That leads to a lack of electron-vendored
chromedriver or mksnapshot binaries where they're supposed to be.
Which in turn causes startup blob creation (via mksnapshot) to fail
toward the end of the Atom build scripts.)
We don't actually support Node older than 10 for successfully
bootstrapping an Atom build, but we should support older Node in the
system requirements checker script so that we can print useful errors,
like ones to tell the user their system's copy of Node is too old!
(It was me that introduced this Node 10.0.0 or above-only syntax
about a year ago... My mistake. It's as good a time as any to fix it!)
Update lockfileVersion to *2*, but that's a side affect from npm
https://github.com/caolan/async/blob/master/CHANGELOG.md#v200
v2.0.0 allows importing functions modularily.
So I changed the code to only import the functions needed
instead of the whole thing.
add migration branch to list of triggers
revert pr trigger
set isReleaseBranch and isSignedZipBranch to true, this is temporary
fix lint
alter config files
set release branch to false
add @azure/storage-blob
This commit enables faster, more-reproducible installs of `apm`,
when bootstrapping/building Atom in `ci` mode.
(with `--ci` or env var `CI` set).
This only affects bootstrapping/building Atom; This should
not make any difference to the built Atom app, or to `apm`'s behavior
as a command-line tool/as a component of Atom.
Details:
As of apm 2.6.2, apm respects a `NO_APM_DEDUPE` env var on Windows.
(It was already supported on Linux and macOS before then.)
When set, this env var disables the deduping
normally performed at the end of apm's postinstall script.
This deduping doesn't work properly when installing apm with `npm ci`,
for unknown reasons. (The deduping algorithm deletes many needed
dependencies, without reconstructing a valid tree.)
Now that `apm` supports `NO_APM_DEDUPE` on all platforms,
we can safely allow installing `apm` with `npm ci`
during the bootstrap script.
Now bootstrapping apm in `ci` mode is faster in two ways:
- `npm ci` is generally faster than `npm install` for clean installs.
- Great for actual automated builds ("CI").
- The `npm dedupe` run is now skipped in `ci` mode.
- The `npm dedupe` was of dubious value in any case
- The `npm dedupe` command was also surprisingly slow
We also benefit from the stronger reproducibility of `npm ci`
compared to `npm install` (guaranteed, version-locked dependencies).
