Skip to content

Conversation

@kmruiz
Copy link
Contributor

@kmruiz kmruiz commented Oct 27, 2025

We are also upgrading the minimum engine to 22, and the dependencies we use for CodeQL to 24, as it's going to be our baseline from now on.

We are also upgrading the minimum engine to 22,
and the dependencies we use for CodeQL to 24, as it's
going to be our baseline from now on.
@addaleax addaleax changed the title chore: Upgrade support to node 22 and 24 feat!: upgrade support to node 22 and 24 Oct 27, 2025
In theory vcbuild.bat should detect where the MSVC DevTools
are located (using vswhere.exe) and setup them correctly. We
are going to verify this behaviour.
Compiling with a snapshot requires compiling twice: a base image
and the image with the snapshot embedded. In that situation, clang-cl
complains that there are precompiled headers that changed between
compilations and does not refresh them, but kills the compilation
process with an error. Due to this, before attempting the second
compilation, we will delete all pch files.
This test was written so we could speed up the feedback loop.
Because we can keep adding more tests, maintaining the GHA workflow
can become a bit cumbersome. This script generates the GHA file
from a template, and adds all the test cases in a matrix. We do this
because each test is expensive in time and disk space, so we do
sometimes hit the GHA limit of 6h or the we fill the disk.
It seems that -g expects a regular expression, and
if the regular expression is invalid, mocha just fails
with Error: null. Using -f, uses a substring comparison,
which is what we need.
nodeSourcePath in Windows refers to a user directory that contains
an alias. For example, something like C:\Users\RUNNER~1 (in GHA) while
MSVC uses the full name like C:\Users\runneradmin. This can make
rimraf not delete the pch files properly. By resolving first, we make
sure that both paths are absolute and unambiguous.
clang-cl does not properly handle pch refresh when a source header
changed after the pch file was generated
This will force Node.js to compile from scratch. It's slower, but
it will only happens on Windows and it will be safer and more
reliable there.
Right now it's failing on the first compilation of the second test, as
we are not doing any clean up. To ensure that we are in a consistent
state in Windows, before attempting compiling, we will make sure we
don't have any old compilation artifact.

This might slow down Windows compilations as they can't reuse cached
files.
@kmruiz kmruiz requested a review from addaleax November 18, 2025 09:49
@kmruiz kmruiz merged commit 3eb9bde into main Nov 18, 2025
76 of 82 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants