chore(deps): update node.js to v22 #135
No reviewers
Labels
No Label
bug
doing
duplicate
enhancement
help wanted
invalid
question
ready
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kompetenzinventar/ki-frontend#135
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "renovate/node-22.x"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
20.18.0-alpine->22.12.0-alpine20.18.0-alpine->22.12.0-alpineRelease Notes
nodejs/node (node)
v22.12.0: 2024-12-03, Version 22.12.0 'Jod' (LTS), @ruyadornoCompare Source
Notable Changes
require(esm) is now enabled by default
Support for loading native ES modules using require() had been available on v20.x and v22.x under the command line flag --experimental-require-module, and available by default on v23.x. In this release, it is now no longer behind a flag on v22.x.
This feature is still experimental, and we are looking for user feedback to make more final tweaks before fully stabilizing it. For this reason, on v22.x, when the Node.js instance encounters a native ES module in require() for the first time, it will emit an experimental warning unless
require()comes from a path that containsnode_modules. If there happens to be any regressions caused by this feature, users can report it to the Node.js issue tracker. Meanwhile this feature can also be disabled using--no-experimental-require-moduleas a workaround.With this feature enabled, Node.js will no longer throw
ERR_REQUIRE_ESMifrequire()is used to load a ES module. It can, however, throwERR_REQUIRE_ASYNC_MODULEif the ES module being loaded or its dependencies contain top-levelawait. When the ES module is loaded successfully byrequire(), the returned object will either be a ES module namespace object similar to what's returned byimport(), or what gets exported as"module.exports"in the ES module.Users can check
process.features.require_moduleto see whetherrequire(esm)is enabled in the current Node.js instance. For packages, the"module-sync"exports condition can be used as a way to detectrequire(esm)support in the current Node.js instance and allow bothrequire()andimportto load the same native ES module. See the documentation for more details about this feature.Contributed by Joyee Cheung in #55085
Added resizable
ArrayBuffersupport inBufferWhen a
Bufferis created using a resizableArrayBuffer, theBufferlength will now correctly change as the underlyingArrayBuffersize is changed.Contributed by James Snell in #55377
Update root certificates to NSS 3.104
This is the version of NSS that shipped in Firefox 131.0 on 2024-10-01.
Certificates added:
Contributed by Richard Lau in #55681
Other Notable Changes
Commits
v22.11.0: 2024-10-29, Version 22.11.0 'Jod' (LTS), @richardlauCompare Source
Notable Changes
This release marks the transition of Node.js 22.x into Long Term Support (LTS)
with the codename 'Jod'. The 22.x release line now moves into "Active LTS"
and will remain so until October 2025. After that time, it will move into
"Maintenance" until end of life in April 2027.
Other than updating metadata, such as the
process.releaseobject, to reflectthat the release is LTS, no further changes from Node.js 22.10.0 are included.
OpenSSL 3.x
Official binaries for Node.js 22.x currently include OpenSSL 3.0.x (more
specifically, the quictls OpenSSL fork).
OpenSSL 3.0.x is the currently designated long term support version that is
scheduled to be supported until 7th September 2026, which is within the expected
lifetime of Node.js 22.x. We are expecting upstream OpenSSL to announce a
successor long term support version prior to that date and since OpenSSL now
follows a semantic versioning-like versioning scheme we expect to be able to
update to the next long term supported version of OpenSSL during the lifetime of
Node.js 22.x.
v22.10.0: 2024-10-16, Version 22.10.0 (Current), @aduh95Compare Source
Notable Changes
New
"module-sync"exports conditionThis release introduces a
"module-sync"exports condition that's enabled whenrequire(esm)is enabled, so packages can supply a synchronous ES module to theNode.js module loader, no matter if it's being required or imported. This is
similar to the
"module"condition that bundlers have been using to supportrequire(esm)in Node.js, and allows dual-package authors to opt into ESM-firstonly on newer versions of Node.js that supports
require(esm)to avoid thedual-package hazard.
Or if the package is only meant to be run on Node.js and wants to fallback to
CJS on older versions that don't have
require(esm):For package authors: this only serves as a feature-detection mechanism for
packages that wish to support both CJS and ESM users during the period when some
active Node.js LTS versions support
require(esm)while some older ones don't.When all active Node.js LTS lines support
require(esm), packages can simplifytheir distributions by bumping the major version, dropping their CJS exports,
and removing the
module-syncexports condition (with onlymainordefaulttargetting the ESM exports). If the package needs to support both bundlers and
being run unbundled on Node.js during the transition period, use both
module-syncandmoduleand point them to the same ESM file. If the packagealready doesn't want to support older versions of Node.js that doesn't support
require(esm), don't use this export condition.For bundlers/tools: they should avoid implementing this stop-gap condition.
Most existing bundlers implement the de-facto bundler standard
moduleexports condition, and that should be enough to support users who want to bundle
ESM from CJS consumers. Users who want both bundlers and Node.js to recognize
the ESM exports can use both
module/module-syncconditions during thetransition period, and can drop
module-sync+modulewhen they no longer needto support older versions of Node.js. If tools do want to support this
condition, it's recommended to make the resolution rules in the graph pointed by
this condition match the Node.js native ESM rules to avoid divergence.
We ended up implementing a condition with a different name instead of reusing
"module", because existing code in the ecosystem using the"module"condition sometimes also expect the module resolution for these ESM files to
work in CJS style, which is supported by bundlers, but the native Node.js loader
has intentionally made ESM resolution different from CJS resolution (e.g.
forbidding
import './noext'orimport './directory'), so it would bebreaking to implement a
"module"condition without implementing the forbiddenESM resolution rules. For now, this just implements a new condition as
semver-minor so it can be backported to older LTS.
Contributed by Joyee Cheung in #54648.
node --runis now stableThis CLI flag runs a specified command from a
package.json's"scripts"object.For the following
package.json:You can run
node --run testand that would start the test suite.Contributed by Yagiz Nizipli in #53763.
Other notable changes
Commits
v22.9.0: 2024-09-17, Version 22.9.0 (Current), @RafaelGSSCompare Source
New API to retrieve execution Stack Trace
A new API
getCallSitehas been introduced to theutilmodule. This API allows usersto retrieve the stacktrace of the current execution. Example:
Thanks to Rafael Gonzaga for making this work on #54380.
Disable V8 Maglev
We have seen several crashes/unexpected JS behaviors with maglev on v22
(which ships V8 v12.4). The bugs lie in the codegen so it would be difficult for
users to work around them or even figure out where the bugs are coming from.
Some bugs are fixed in the upstream while some others probably remain.
As v22 will get stuck with V8 v12.4 as LTS, it will be increasingly difficult to
backport patches for them even if the bugs are fixed. So disable it by default
on v22 to reduce the churn and troubles for users.
Thanks to Joyee Cheung for making this work on #54384
Exposes X509_V_FLAG_PARTIAL_CHAIN to tls.createSecureContext
This releases introduces a new option to the API
tls.createSecureContext. Fornow on users can use
tls.createSecureContext({ allowPartialTrustChain: true })to treat intermediate (non-self-signed) certificates in the trust CA certificate
list as trusted.
Thanks to Anna Henningsen for making this work on #54790
Other Notable Changes
Deprecations
Commits
v22.8.0: 2024-09-03, Version 22.8.0 (Current), @RafaelGSSCompare Source
New JS API for compile cache
This release adds a new API
module.enableCompileCache()that can be used to enable on-disk code caching of all modules loaded after this API is called.Previously this could only be enabled by the
NODE_COMPILE_CACHEenvironment variable, so it could only set by end-users.This API allows tooling and library authors to enable caching of their own code.
This is a built-in alternative to the v8-compile-cache/v8-compile-cache-lib packages,
but have better performance and supports ESM.
Thanks to Joyee Cheung for working on this.
New option for vm.createContext() to create a context with a freezable globalThis
Node.js implements a flavor of
vm.createContext()and friends that creates a context without contextifying its globalobject when vm.constants.DONT_CONTEXTIFY is used. This is suitable when users want to freeze the context
(impossible when the global is contextified i.e. has interceptors installed) or speed up the global access if they
don't need the interceptor behavior.
Thanks to Joyee Cheung for working on this.
Support for coverage thresholds
Node.js now supports requiring code coverage to meet a specific threshold before the process exits successfully.
To use this feature, you need to enable the
--experimental-test-coverageflag.You can set thresholds for the following types of coverage:
--test-coverage-branches=<threshold>--test-coverage-functions=<threshold>--test-coverage-lines=<threshold><threshold>should be an integer between 0 and 100. If an invalid value is provided, aTypeErrorwill be thrown.If the code coverage fails to meet the specified thresholds for any category, the process will exit with code
1.For instance, to enforce a minimum of 80% line coverage and 60% branch coverage, you can run:
Thanks Aviv Keller for working on this.
Other Notable Changes
Commits
v22.7.0: 2024-08-22, Version 22.7.0 (Current), @RafaelGSSCompare Source
Experimental transform types support
With the new flag
--experimental-transform-typesit is possible to enable thetransformation of TypeScript-only syntax into JavaScript code.
This feature allows Node.js to support TypeScript syntax such as
Enumandnamespace.Thanks to Marco Ippolito for making this work on #54283.
Module syntax detection is now enabled by default.
Module syntax detection (the
--experimental-detect-moduleflag) is nowenabled by default. Use
--no-experimental-detect-moduleto disable it ifneeded.
Syntax detection attempts to run ambiguous files as CommonJS, and if the module
fails to parse as CommonJS due to ES module syntax, Node.js tries again and runs
the file as an ES module.
Ambiguous files are those with a
.jsor no extension, where the nearest parentpackage.jsonhas no"type"field (either"type": "module"or"type": "commonjs").Syntax detection should have no performance impact on CommonJS modules, but it
incurs a slight performance penalty for ES modules; add
"type": "module"tothe nearest parent
package.jsonfile to eliminate the performance cost.A use case unlocked by this feature is the ability to use ES module syntax in
extensionless scripts with no nearby
package.json.Thanks to Geoffrey Booth for making this work on #53619.
Performance Improvements to Buffer
Performance of Node.js Buffers have been optimized through multiple PR's with significant
improvements to the
Buffer.copyandBuffer.writemethods. These are used throughoutthe codebase and should give a nice boost across the board.
Thanks to Robert Nagy for making this work on #54311,
#54324, and #54087.
Other Notable Changes
Commits
v22.6.0: 2024-08-06, Version 22.6.0 (Current), @RafaelGSSCompare Source
Experimental TypeScript support via strip types
Node.js introduces the
--experimental-strip-typesflag for initial TypeScript support.This feature strips type annotations from .ts files, allowing them to run
without transforming TypeScript-specific syntax. Current limitations include:
enumsornamespaces.Thanks Marco Ippolito for working on this.
Experimental Network Inspection Support in Node.js
This update introduces the initial support for network inspection in Node.js.
Currently, this is an experimental feature, so you need to enable it using the
--experimental-network-inspectionflag.With this feature enabled, you can inspect network activities occurring within a JavaScript application.
To use network inspection, start your Node.js application with the following command:
Please note that the network inspection capabilities are in active development.
We are actively working on enhancing this feature and will continue to expand its functionality in future updates.
httpandhttpsmodules only.feature request on the Chrome DevTools side is addressed.
Thanks Kohei Ueno for working on this.
Other Notable Changes
Commits
v22.5.1: 2024-07-19, Version 22.5.1 (Current), @richardlauCompare Source
Notable Changes
This release fixes a regression introduced in Node.js 22.5.0. The problem is known to display the following symptoms:
FATAL ERROR: v8::Object::GetCreationContextChecked No creation context available#53902npm error Exit handler never called!npm/cli#7657Usage Error: Couldn't find the node_modules state file - running an install might help (findPackageLocation)yarnpkg/berry#6398Commits
v22.5.0: 2024-07-17, Version 22.5.0 (Current), @RafaelGSS prepared by @aduh95Compare Source
Notable Changes
Commits
v22.4.1: 2024-07-08, Version 22.4.1 (Current), @RafaelGSSCompare Source
This is a security release.
Notable Changes
Commits
v22.4.0: 2024-07-02, Version 22.4.0 (Current), @targosCompare Source
Notable Changes
Experimental Web Storage API
API stability updates
Other Notable Changes
Commits
v22.3.0: 2024-06-11, Version 22.3.0 (Current), @RafaelGSSCompare Source
Notable Changes
Commits
v22.2.0: 2024-05-15, Version 22.2.0 (Current), @targosCompare Source
Notable Changes
Commits
v22.1.0: 2024-05-02, Version 22.1.0 (Current), @targos prepared by @aduh95Compare Source
module: implement
NODE_COMPILE_CACHEfor automatic on-disk code cachingThis patch implements automatic on-disk code caching that can be enabled
via an environment variable
NODE_COMPILE_CACHE=/path/to/cache/dir.When set, whenever Node.js compiles a CommonJS or a ECMAScript Module,
it will use on-disk V8 code cache
persisted in the specified directory
to speed up the compilation. This may slow down the first load of a
module graph, but subsequent loads of the same module graph may get
a significant speedup if the contents of the modules do not change.
Locally, this speeds up loading of
test/fixtures/snapshot/typescript.jsfrom ~130ms to ~80ms.
To clean up the generated code cache, simply remove the directory.
It will be recreated the next time the same directory is used for
NODE_COMPILE_CACHE.Compilation cache generated by one version of Node.js may not be used
by a different version of Node.js. Cache generated by different versions
of Node.js will be stored separately if the same directory is used
to persist the cache, so they can co-exist.
Caveat: currently when using this with V8 JavaScript code coverage, the
coverage being collected by V8 may be less precise in functions that are
deserialized from the code cache. It's recommended to turn this off when
running tests to generate precise coverage.
Contributed by Joyee Cheung in #52535.
Other Notable Changes
Commits
v22.0.0: 2024-04-24, Version 22.0.0 (Current), @RafaelGSS and @marco-ippolitoCompare Source
We're excited to announce the release of Node.js 22!
Highlights include require()ing ESM graphs, WebSocket client, updates of the V8 JavaScript engine, and more!
As a reminder, Node.js 22 will enter long-term support (LTS) in October, but until then, it will be the "Current" release for the next six months.
We encourage you to explore the new features and benefits offered by this latest release and evaluate their potential impact on your applications.
Other Notable Changes
Semver-Major Commits
Semver-Minor Commits
Semver-Patch Commits
v20.18.1: 2024-11-20, Version 20.18.1 'Iron' (LTS), @marco-ippolitoCompare Source
Notable Changes
Commits
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR has been generated by Renovate Bot.
fde1ec2d23to11ebc37c5611ebc37c56tof54d621b66f54d621b66toeafa8a59aceafa8a59acto1d0b51dff11d0b51dff1to2fa5deb48b2fa5deb48bto3e646a2b363e646a2b36to4798e10afa4798e10afato8f61be09b68f61be09b6to721668c71a721668c71ato2211299c8f2211299c8fto126f1238fc126f1238fcto1f2404dd621f2404dd62todf028f2498df028f2498toed5d5a0180ed5d5a0180tod2b483b4e9Checkout
From your project repository, check out a new branch and test the changes.