Skip to content

2026 Major Version Tracking#1619

Draft
rowanmanning wants to merge 26 commits intomainfrom
2026-majors
Draft

2026 Major Version Tracking#1619
rowanmanning wants to merge 26 commits intomainfrom
2026-majors

Conversation

@rowanmanning
Copy link
Member

@rowanmanning rowanmanning commented Jan 7, 2026

@rowanmanning rowanmanning added this to the Major Versions 2026 milestone Jan 7, 2026
@rowanmanning rowanmanning added the breaking change Indicates that the feature will require a major version bump. label Jan 7, 2026
@rowanmanning rowanmanning force-pushed the 2026-majors branch 2 times, most recently from 0d85478 to ebb5414 Compare January 14, 2026 18:53
@rowanmanning rowanmanning force-pushed the 2026-majors branch 2 times, most recently from 71a41ca to 6c82d06 Compare January 23, 2026 16:30
Node.js 20 goes end-of-life in April 2026 so this will form part of the
next major versions of our packages.
This means we're running with the latest versions of the Node.js majors
that we support. I also switched our publish workflow to run on Node.js
24 rather than 22 - 24 is now the latest LTS version and 22 is in
maintenance.
Node.js 22.12 removes the need for the `--experimental-require-module`
CLI flag when importing native ESM into CommonJS contexts. We'd like to
migrate Reliability Kit to be ESM and we'd like for the teams who use it
to not have to include this CLI flag.

We're taking the decision to drop support for Node.js versions below
22.12 in order to support this.

This is the first step towards us migrating to native ESM, see #1479.
This will allow us to use conditional exports when we migrate to native
ESM. It's also the more modern way of doing package exports as it's a
lot more flexible than the top-level `main` property.

Partially as a result of this change and partially because we'll be
switching to TypeScript, I've also outlined some more strict
requirements for Reliability Kit's usage with TypeScript, and the
settings we recommend and support.
rowanmanning and others added 19 commits January 26, 2026 15:47
This migrates serialize-error and serialize request packages to use the
Node.js test runner instead of Jest. This halves the time it takes to
run these tests and brings us a step closer to getting rid of Jest.
This was simpler than I thought. We need a lot of command line arguments
to actually run the tests (experimental mock modules, snapshots, and
code coverage) but I think that's fine - they're all relatively stable
and mean we can test with zero dependencies.

Test runs drop from ~250ms to ~70ms.
This is probably the biggest suite of tests to migrate. It wasn't _easy_
but it was less of a pain than I thought. The Node.js test runner caters
for everything we need.

The only issue at the mo, as stated before, is that we need a lot of CLI
arguments to enable all the testing features we need. These will slowly
go away so I'm not worried.

Test runs didn't speed up for this because the bulk of the time we spend
is waiting for child processes in the end-to-end tests.
Nice and easy. Test runs go from ~200ms to ~70ms.
These tests aren't giving us anything because TypeScript will already
have validated that our exported object is a valid config file. This
brings the eslint-config package in line with the biome-config package.
This one's relatively straightforward. Test run drops from ~150ms to
~65ms.
Nice and easy. Run drops from ~120ms to ~50ms.
Test run time drops from ~2,100ms to ~1,800ms
Test runs from from ~125ms to ~60ms.
Co-Authored-By: Camille Croci <camillecroci@users.noreply.github.com>
Co-Authored-By: Camille Croci <camillecroci@users.noreply.github.com>
Co-Authored-By: Camille Croci <camillecroci@users.noreply.github.com>
Co-Authored-By: Camille Croci <camillecroci@users.noreply.github.com>
These were not actually testing anything previously, and now we're being
more explicit about which error properties we test. This fixes the
snapshot tests.
This is a code smell. If you need to specify which files need coverage
then you're not mocking enough. So I've removed all the easy ones.

Part of my strategy for getting rid of these was to stop covering
end-to-end tests, which shouldn't be mocking anything. The unit tests
should provide 100% coverage and the end-to-end tests should be an added
layer of safety on top of these and should not rely on mocking.

This involved me splitting out the test commands, which is useful anyway
because it means we can run the unit tests alone much quicker - the
end-to-end tests are normally the slow ones.

One test remains that needs the "include" flag, we should aim to remove
this and mock things properly one day but let's not make too many more
changes as part of this initial work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

breaking change Indicates that the feature will require a major version bump.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant