Software's conformance to standards and its certification is not the pinnacle to shoot for. It is the absolute lowest bar.

Having users keep a list of ESM-only dependencies to ignore "transform" on is the, as advertised, delightful Jest experience? As a maintainer of ESM-only modules I am not delighted being the support channel for @jestjs_ users who struggle to use web-compatible ESM modules.

FWIW the WebCryptoAPI in Node.js had these since August 2022.

WebCryptoAPI Ed25519 and X25519 algorithms are finally unflagged in Chrome 137, Edge 137 will follow shortly after and then these are available in all browsers. This is long overdue and is arguably might be seen as DOA given we're now shifting our focus to PQC algorithm support.

RT @_rafaelgss: A warm welcome to our newest Node.js TSC member: @_panva . Happy to see you onboard!.

jsr recently added download stats to the UI which also shows user adoption is nearing 0 even for very popular projects. Apart from bug fixes and less punishment for module authors, what's missing? For users? For module authors? Incentive for one, what else?.

Reality is that its doc generation drops doc inherited from the "implements" keyword, doesn't support full github flavored markdown, it punishes lack of useless interface docs with score deductions, lacks support for undeclared type dependencies necessary for a plugin ecosystem.

jsr seems intended to be super convenient for module authors who already adopted typescript, it build js, generates docs, incentivises inline docs using tsdoc, generally avoids having to setup much tooling.

There's a reason for those constant time checks. As flawed as they may be with eager optimizations done by js engines they still serve a purpose.

I've seen recent code changes that dealt with the buffer-equal-constant-time mishap in Node.js v24.0.0 by replacing it with the buffer-equal module via package manager overwrites. Please know that doing so makes your code vulnerable to timing attacks.

Did you move off of Node.js v18.x yet? 2 days 'till EOL

Thank you @ItsAndreKoenig for sponsoring me on @github. You can join them and discover my other standards-related projects at my sponsors profile:

RT @satanacchio: Node.js v20.19.0 is out 🤩. This is a special minor release ✨.Although v20 is in maintenance mode, meaning only patch are e….

JSR still has a long way to go to be taken seriously by maintainers, at least from the experience I'm having. Does anyone believe it'll ever become THE registry to use?.

There is no reason for this code to throw because of a polyfill being in place. globalThis.process?.getBuiltinModule?.('node:buffer')?.Buffer. That's wrong and to the detriment of end users. getBuiltinModule in the polyfill should either not exist or always return null.

Mind you this is the intention behind that API. "ES Modules that need to support other environments can use it to conditionally load a Node.js built-in when it is run in Node.js". Blocking this API with an always-error polyfill goes against what the API is for.

FWIW because it's unlikely to be understood as a rant, this should not be a vulnerability/issue <redacted> users ever see and even if so it's not high severity.

sigh. Severity: High.Short Description: Package can be replaced with a <redacted> optimized override.

Great job!.

ELTS (Extended Long Term Support) every three even-numbered majors. Paid for by enterprises who value stability and don't want a Node upgrade team on standby every year. One can only wish. I brought the idea up on the collaborator summit in Dublin late last year. Didn't stick.