Unbundling npm; new JS runtime by Amazon; Vite 5.1; February TC39 meeting; ES stage 2.7; Web IDL for

“A heated debate is happening in the Node.js community over a proposal to enable Corepack by default that was opened in November 2023. This sparked the question of whether npm would be provided through Corepack moving forward, as some contributors hold the opinion that the eventual goal of its integration is to uncouple Node.js releases and npm releases.”

How does Corepack work? If it is enabled and you execute <some-package-manager> install inside a project directory, Corepack will intercept that command (quoting the Corepack readme):

• If the local project is configured for the package manager you’re using, Corepack will silently download and cache the latest compatible version.
• If the local project is configured for a different package manager, Corepack will request you to run the command again using the right package manager – thus avoiding corruptions of your install artifacts.
• If the local project isn’t configured for any package manager, Corepack will assume that you know what you’re doing, and will use whatever package manager version has been pinned as “known good release”.

• Built in Rust, uses QuickJS as JavaScript engine
• Supports ECMAScript 2020 and many Node.js APIs. Supporting all of them is not a goal of the project.
• Focuses on fast startup and efficient memory usage for server-side code. QuickJS does not have a just-in-time compiler (JIT). That means that longer-running code is often slower. But it also has two benefits (quoting the project’s readme):
  • JIT compilation is a notably sophisticated technological component, introducing increased system complexity and contributing substantially to the runtime’s overall size.
  • Without the JIT overhead, LLRT conserves both CPU and memory resources that can be more efficiently allocated to code execution tasks, thereby reducing application startup times.

• New Vite Runtime API is an upgrade for Vite’s current server-side rendering primitives with the following benefits (quoting the blog post):
  • Support for HMR during SSR.
  • It is decoupled from the server, so there is no limit on how many clients can use a single server - every client has its own module cache (you can even communicate with it how you want – using message channel/fetch call/direct function call/websocket).
  • It doesn’t depend on any node/bun/deno built-in APIs, so it can run in any environment.
  • It’s easy to integrate with tools that have their own mechanism to run code (you can provide a runner to use eval instead of new AsyncFunction for example).
• Improved support for .css?url
• build.assetsInlineLimit now supports a callback
• Improved HMR for circular import
• Support ssr.external: true to externalize all SSR packages
• Expose close method in the preview server
• Various performance improvements
• Deprecated as option in import.meta.glob
• Removed experimental build-time pre-bundling

• Several proposals advanced to stage 1.
• Stage 2: “Promise.try”
• Stage 3: “Uint8Array to/from base64 and hex”
• Stage 4: “ArrayBuffer.prototype.transfer and friends”
• Several proposals became inactive.

• “Stage 2.7 is equivalent to what we used to call Stage 3. It means that the design is considered complete, we have a full specification, and we need to write code (tests and non-polyfill implementations) to gain feedback and make progress. It’s a strong signal.”
• “Stage 3 has been strengthened and now also means that test262 conformance tests are ready. This is a useful signal to JS engines that a proposal is truly ready to be implemented.”
• “Why did we do this? We separated out the ‘Approved in Principle: Spec Ready’ stage from the later ‘Recommended for Implementation: Tests Ready’ stage to reduce wasted effort in writing tests before spec stability, whilst also clarifying the test readiness message to engines.”