Joyee Cheung
@joyeecheung.bsky.social
She/her. I contribute to Node.js and V8. I post about museums, food, plants and other stuff too. https://github.com/joyeecheung
We need a new word: the bike factor
October 31, 2025 at 10:54 AM
We need a new word: the bike factor
Yes, that’s a docker container with a pre-built checkout of Node.js that you can mount your local checkout Node.js on, compile without having to rebuild V8 (usually), and test changes in Node.js in an isolated environment (with third party code from the bugs reports for example)
October 29, 2025 at 6:06 PM
Yes, that’s a docker container with a pre-built checkout of Node.js that you can mount your local checkout Node.js on, compile without having to rebuild V8 (usually), and test changes in Node.js in an isolated environment (with third party code from the bugs reports for example)
No particular reason other than it seems a bit more common when I skim over the common shipping patterns
October 3, 2025 at 3:06 PM
No particular reason other than it seems a bit more common when I skim over the common shipping patterns
But that example is pretty extreme, not every CJS exports thousands of names
September 29, 2025 at 9:24 AM
But that example is pretty extreme, not every CJS exports thousands of names
Ah, that one, there was already an issue and a suggestion to reduce the perf impact if the package provides a wrapper that makes it easier to parse exports: github.com/nodejs/node/...
`import "typescript"` slower than `require("typescript")` due to `cjs-module-lexer` overhead · Issue #59913 · nodejs/node
Version Node.js v24.8.0 Node.js v22.18.0 Platform Observed on macOS (x64), but likely reproducible on other platforms. Description When loading typescript, using import is ~100ms slower than requir...
github.com
September 29, 2025 at 9:22 AM
Ah, that one, there was already an issue and a suggestion to reduce the perf impact if the package provides a wrapper that makes it easier to parse exports: github.com/nodejs/node/...
…or some heuristics can be used to assume .js in node_modules governed by the same package.json have the same format so that they don’t need to be repeatedly parsed
September 29, 2025 at 9:20 AM
…or some heuristics can be used to assume .js in node_modules governed by the same package.json have the same format so that they don’t need to be repeatedly parsed
The issue can be alleviated if more packages explicitly specify the type field; or if the toolchains can reuse the parsed result (e.g. for detecting exports) they could reuse it and not just throw it away after syntax detection.
September 29, 2025 at 9:19 AM
The issue can be alleviated if more packages explicitly specify the type field; or if the toolchains can reuse the parsed result (e.g. for detecting exports) they could reuse it and not just throw it away after syntax detection.
That is pretty much what Node.js does, except that Node.js does reuse the parsed result because it actually needs to parse it and run it anyway. It warns against results it cannot reuse though (ESM in .js under node_modules without “type” field in package.json).
September 29, 2025 at 9:12 AM
That is pretty much what Node.js does, except that Node.js does reuse the parsed result because it actually needs to parse it and run it anyway. It warns against results it cannot reuse though (ESM in .js under node_modules without “type” field in package.json).
I noticed, but my connection to GitHub at home has always been slow no matter it’s match day or not 😬
September 20, 2025 at 9:55 AM
I noticed, but my connection to GitHub at home has always been slow no matter it’s match day or not 😬
Yeah it would be odd to say Node.js resent ESM when folks are actively making it less painful to use / ship. At most, there are still wonky edge cases because of technicalities, but bugs always show up when you try to get two very different semantics work together no matter you love them or not.
September 14, 2025 at 2:34 PM
Yeah it would be odd to say Node.js resent ESM when folks are actively making it less painful to use / ship. At most, there are still wonky edge cases because of technicalities, but bugs always show up when you try to get two very different semantics work together no matter you love them or not.
If there's some enterprise value not represented in a project mostly built by volunteers, the most probable reason is just: no enterprise is investing in the work about this, or not enough. Then it is unlikely to get done by unpaid volunteers in their spare time until investment comes.
September 14, 2025 at 1:34 PM
If there's some enterprise value not represented in a project mostly built by volunteers, the most probable reason is just: no enterprise is investing in the work about this, or not enough. Then it is unlikely to get done by unpaid volunteers in their spare time until investment comes.