Node Removes Corepack, Bun Runs Native C From JavaScript

Node.js is planning to remove Corepack, a tool that has been included in Node.js since version 16.13.0.

Corepack simplified managing different Node.js versions and package managers like npm, yarn, and pnpm across projects. It also provided a way to install and use these tools without having to worry about compatibility issues or manual configuration.

There’s an unusual story about how that decision happened, involving plans to make Corepack enabled by default and then doing a 180 and deciding to remove it, which Sarah Gooding of Socket shared in August. YouTube and frontend developer Theo Browne, aka Theo – t3.gg, shared why removing Corepack is a disappointing move for many web developers. Instead of using npm, developers could just use Corepack. But alas, those days are gone.

Gooding referenced web developer Nick Ribal.

“I’ll also add my deep disappointment with this sad state of affairs,” Ribal said. “Lots of people choose not to use npm for lots of valid reasons. For this crowd, Corepack has been nothing short of a lifeline, which this PR aims to sever. It’ll be a terrible regression and will harm many node users. It is actively hostile and I wish more people realized that.”

For their part, the PMWG (Package Maintenance Working Group) members behind the decision say it’s better for Corepack to evolve independently since the maintainers — with rare exceptions — haven’t shown up to meetings to work with the PMWG “for the better part of a decade,” according to developer and open source maintainer Jordan Harband.

Bun Now Supports Running Native C from JavaScript

Bun version 1.1.28 provided experimental support for compiling and running native C from JavaScript.

Bun is a JavaScript runtime, bundler, test runner, and package manager rolled into one. It positions itself as an alternative to Node. But adding the ability to compile and run native C from JavaScript does beg the question: Why would you do that?

“From compression to cryptography to networking to the web browser you’re reading this on, the world runs on C,” wrote Jarred Sumner, creator of Bun. “If it’s not written in C, it speaks the C ABI (C++, Rust, Zig, etc.) and is available as a C library. C and the C ABI are the past, present, and future of systems programming.”

“You probably won’t get much of a performance gain from micro-optimizing small parts of your codebase through C, but happy to be proven wrong!”
— Jared Sumner, creator of Bun

This is a low-boilerplate way to use C libraries and system libraries from JavaScript, he said, adding that this feature allows the same project that runs JavaScript to also run C without a separate build step.

Among the use cases he cited are:

“It’s good for glue code that binds C or C-like libraries to JavaScript. Sometimes, you want to use a C library or system API from JavaScript, and that library was never meant to be used from JavaScript,” Sumner added.

It’s currently possible to achieve this by compiling to WebAssembly or writing a N-API (napi) addon or V8 C++ API library addon, the team explained. But both are suboptimal, explained Sumner.

Writing a N-API or other addon is suboptimal because compiling native addons breaks CI and compiling native addons is complicated for maintainers, plus it comes at a 3x performance hit, he noted.

On the other hand, WebAssembly can do this but its isolated memory model comes with serious tradeoffs, the team wrote, including an inability to make system calls and a requirement to clone everything.

“Modern processors support about 280 TB of addressable memory (48 bits). WebAssembly is 32-bit and can only access its own memory,” Sumner wrote. “That means by default, passing strings and binary data JavaScript <=> WebAssembly must clone every time. For many projects, this negates any performance gain from leveraging WebAssembly.”

The latest version of Bun, released Friday, builds on this by adding N-API (nap) support to cc.

“This makes it easier to return JavaScript strings, objects, arrays and other non-primitive values from C code,” wrote Sumner. ”You can continue to use types like int, float, double to send & receive primitive values from C code, but now you can also use N-API types! Also, this works when using dlopen to load shared libraries with bun:ffi (such as Rust or C++ libraries with C ABI exports).”

That said, developers probably don’t want to use the ability to run C in JavaScript for compiling large projects, such as PostgreSQL or SQLite, he added.

“TinyCC compiles to decently performant C, but it won’t do advanced optimizations that Clang or GCC does like autovectorization or very specialized CPU instructions,” Sumner wrote. “You probably won’t get much of a performance gain from micro-optimizing small parts of your codebase through C, but happy to be proven wrong!”

Astro 5.0 Beta Available With Content Layer

The content-focused web framework Astro released the beta of version 5.0 this week with a now-stable Astro Content Layer that offers a new way to handle content. This beta also makes stable server islands, which allow developers to mix static and personalized content on site pages.

The content layer is a “powerful new way to organize” local content and is built with type safety, and scales to thousands of pages, wrote Astro Maintainer Matt Kane in a deep dive of the content layer.

The content layer will handle Content Collections, which were introduced in Astro 2 as a way to “provide a best-in-class developer experience for local files such as Markdown and MDX.” But the functionality struggled with scale, noted Kane, and developers wanted the same benefits for all content, including remote APIs.

Server islands are a new primitive that build upon Astro’s existing islands architecture, according to this post by team member Erika.

“This feature is notably useful for content-driven websites that mix dynamic and static content on the page,” Erika wrote. “For instance, for an e-commerce site, you could defer the rendering of product recommendations until after the initial page load, providing a faster initial page load time while still delivering personalized content.”

This release also marks as stable the astro:env, which is a new way to manage environmental variables. Astro:env is a “built-in module that provides a type-safe way to define and access environment variables,” she added.

Finally, this update adds merged static and hybrid output modes, which makes it easier to create a website with both static, cached, performant pages and rendered on-demand, dynamic pages, Erika added.

“Astro’s new output: ‘static’ mode, the default, now allows you to render individual routes at runtime on the server just by adding an adapter, no other configuration is required,” she stated.

Next.js to Relax React 19 Requirement for Pages Router

Next.js Logo on dark background

Next.js Logo

Vercel Software Engineering Manager Jimmy Lai shared via a tweet that Vercel has made developer experience improvements in the canary version of Next.js 15. In particular, they’ve worked on Turbopack’s stability and performance, making it a “pleasure to use,“ Lai said.

He also noted that the team has decided to make a few changes to ease the adoption of Next 15, based on a poll and conversations with developers.

First, Next.js will “relax the React 19 requirement for the Pages Router, so developers can upgrade in their own time.” Second, for the app router, the team will not block not the React 19 GA to mark Next 15 as stable.

“We’ve tested it extensively and are confident in its stability,” Lai said.

The final release candidate should be available in a few weeks with “some minor changes and bug fixes,” and after that, there will be a stable release, he concluded.

Vite 6.0.0 Beta Released with Revamped API

The Vite team is looking for feedback from anyone building on top of the development server and experimenting with its new Module Runner and Environment API, according to a recent tweet.

The Environment API was introduced in Vite 5.1 under the same “Vite Runtime API.” It’s been revised and with Vite 6 is released as experimental.

SolidHack Prizes Total $15,000

Last year’s first SolidHack was so successful, the Solid team said, it’s bringing back the event for a second year. This year, the prize pool totals $15,000, the Solid team announced this week. The event will start Oct. 31 and run through Nov. 14.

“Solid and the ecosystem have matured considerably and SolidStart is now 1.0,” the team wrote. “We’re giving the talented developers in our community an incredible opportunity to show what they got and win prize money.”

Additional contest details will be announced on Oct. 1, but as you might expect from web developers, there’s already a website for the hackathon.

Group Created with Sketch.

 

 

 

 

Top