Per https://nodejs.org/en/about/releases/:
* Node.js 19 became "maintenance" on April 1st.
* Node.js 20 became "current" on April 18th, and will become "active LTS" on October 24th.
In order prepare for potentially breaking changes, update the tested Node.js versions from 18 and
19 to 18 and 20.
By the way, refer to JDK 20 installation, which is the latest release.
Per https://nodejs.org/en/about/releases/:
* Node.js 16 became "maintenance" and Node.js 19 became "current" on October 18.
* Node.js 18 will become "active LTS" on October 25.
In order prepare for potentially breaking changes, update the tested Node.js
versions from 16 and 18 to 18 and 19.
As usual, also bump its helper crates (`js-sys`, `web-sys` and
`wasm-bindgen-futures`) to the latest versions.
Due to https://github.com/rustwasm/wasm-bindgen/pull/3031, use the
`serde-wasm-bindgen` crate as a replacement to the deprecated
`JsValue::from_serde` function.
Based on the work in #6717, plus additional adaptions mentioned in
https://github.com/gfx-rs/wgpu/blob/master/CHANGELOG.md#wgpu-013-2022-06-30,
and more not-mentioned but required changes.
Also bump `wasm-bindgen` to `0.2.81` (along with its helper crates), as
required by the new `wgpu` version.
Note that I don't fully understand some of the required changes, notably:
* `wgpu::PresentMode::Mailbox` no longer works on my machine (Windows 11) -
The `wgpu` documentation says that `wgpu::PresentMode::Fifo` is the
only guaranteed to be supported, so I switched over to it instead.
* `self.staging_belt.recall()` doesn't return a `Future` anymore -
I assume it became synchronous so I simply removed the `executor`
from there.
There seems to be no good reason for testing on Node.js other than
the current LTS. Moreover, npm@6 has a wontfix issue when upgrading
to 8.4 on Windows, which requires a complex workaround: https://github.com/npm/cli/issues/4341#issuecomment-1040608101.
So avoid it by simply not supporting it.
Per https://github.com/actions/virtual-environments/issues/4856,
`windows-latest` will default to `windows-2022` soon (not later than
March, 6). Since it seems like we still run on `windows-2019`, force the
migration by specifying `windows-2022` explicitly.
Since https://github.com/actions/virtual-environments/pull/5050 is
merged, this should fix the failing Web tests on mismatched Chrome and
chromedriver versions.
TODO: Once `windows-latest` defaults to `windows-2022` (again, March, 6),
change back to `windows-latest`.
Upgrading to npm 8.4 on Windows is currently broken: https://github.com/npm/cli/issues/4341
This was avoided by disabling tests on Windows Node 14 in #6167.
Re-enable them by staying on npm 8.3 instead.
`lerna` is a bit stale, and as such it currently has some outdated
dependencies which Dependabot warns on.
Fortunately, npm 7 supports monorepos natively, via "workspaces". So
simply replace `lerna` with this feature. The migration is pretty
neat and requires a very little invervention.
Because Node.js 14 comes with npm 6 by default, upgrade it manually
as shown in https://github.com/bahmutov/npm-install/issues/103#issuecomment-931226602.
As usual, also bump its helper crates (`js-sys`, `wasm-bindgen-futures`)
to the latest versions, except for `web-sys` which is locked by wgpu
to 0.3.50.
The previous approach of `paths-ignore` was flawed because currently
it doesn't interact well with GitHub's "Require status checks to pass
before merging" setting. As a result, PRs that didn't trigger all
workflows couldn't be merged, because GitHub waited for the skipped
workflows to finish.
`dorny/paths-filter` is a somewhat elegant workaround proposed in
https://stackoverflow.com/questions/66751567.
* dev: run workflows only if certain file paths change
* fix: looks like you can't ? a /
* feat: simpler approach
Don't run Rust if only package.json, package-lock.json or anything under
web/packages has changed.
Don't run either if they only have docs changes.
Nathan Adams