Highlights from the Void just dropped ✨
Watch our February recap and go a bit deeper into the highlights!
Learn about the latest updates to Vite, Vitest, Rolldown, Oxlint, Oxfmt, and what's happening in the community.
www.youtube.com/watch?v=7Rj6...
If you've loved using Oxlint's type-aware linting feature, then please consider sponsoring auvred too: github.com/sponsors/auv...
VoidZero sponsorship announcement card with dark purple background. Left side shows the VoidZero logo, a message reading "Thank you for moving the ecosystem forward!" with a gradient highlight, and a $10,000 sponsorship badge with a heart icon. Right side features a profile card for @auvred showing their GitHub avatar and the tagline "Creator of tsgolint".
VoidZero is excited to sponsor auvred for $10,000 as a small thank you for all their contributions that push the ecosystem forward.
Thank you auvred for creating tsgolint and generously offering to continue its development under the Oxc organization.
If this was your only Babel plugin, you can simplify your setup and should see faster builds.
Credits to the `babel-plugin-styled-components` authors. Oxc's implementation is largely based their work.
More info in the Oxc docs: oxc.rs/docs/guide/u...
Using styled-components with @vite.dev 8?
Oxc, which powers Vite's transforms, includes built-in styled-components support. It is covering most features of `babel-plugin-styled-components`:
◆ displayName for debugging,
◆ SSR,
◆ minification,
◆ and more.
All running natively in Rust.
Congrats to @npmx.dev on launching their alpha!
We share the same vision: making JavaScript developers more productive.
They chose to build on the VoidZero toolchain, and their feedback has already shipped real performance improvements back to the community.
This is open source at its best.
npmx is now in alpha: this is our story, as told by our team and friends
✨ What's New in ViteLand: February 2026 Recap
◆ Oxfmt Beta: 100% Prettier conformance
◆ @vite.dev 8 includes devtools
◆ @vitest.dev 4.1 beta adds aroundEach/aroundAll hooks
◆ @rolldown.rs becomes 9.6% faster
◆ Oxlint now supports 59/61 ts-eslint rules
◆ NestJS migrates to Vitest
◆ and much more 👀
Screenshot of VoidZero supporting npmx with $500 USD / month
A modern browser for the npm registry that nudges the ecosystem towards best practices and standards perfectly aligns with our mission: to make the next generation of JS developers more productive than ever before.
We're happy to support our friends at @npmx.dev!
In case of @rolldown.rs, the bundler handles tree shaking at the module level, then hands off to the Oxc minifier for statement-level DCE. Both are part of the same toolchain and built to work together.
Learn more in our in-depth Rolldown DCE chapter
rolldown.rs/in-depth/dea...
In practice, both work together in a pipeline:
◆ Your bundler tree-shakes unused exports across modules
◆ Then, your minifier (e.g. Oxc) then runs DCE to clean up what's left inside each module
Technically, tree shaking is really a type of DCE that happens at the module/export level.
Dead code elimination (DCE) removes dead code within a module. Think unused variables, or unreachable code.
```ts
function process(x) {
if (false) { log('') } // removed
const answer = 42 // removed
return x * 2
}
console.log(process(4))
```
Tree shaking removes unused exports across modules.
```ts
// math.ts
export function add(a, b) { return a + b }
export function mult(a, b) { return a * b }
// app.ts
import { add } from './math.ts'
```
You import `add` but not `mult`? The bundler drops unused exports This is called tree shaking.
Tree shaking and Dead Code Elimination are often used interchangeably but they are not the same!
While both work together to make your bundle smaller, there is a difference...
Built on top of @vite.dev 8 and @rolldown.rs.
RSC support via Vite's RSC plugin.
Linting via Oxlint.
Worried about too many small chunks? `entriesAwareMergeThreshold` has you covered.
Time to reduce your initial JavaScript ✨
Want more info? Take a look at our REPL example (link to the docs inside too!)
repl.rolldown.rs#eNqVWIty27gV...
Infographic showing Rolldown's entriesAware code splitting feature in 3 steps. Step 1 shows three entry points (Dashboard using chart.js, Admin using marked, Landing using gsap - all sharing es-toolkit). Step 2 shows the problem: without entriesAware, all entries load a single 305KB vendor.js containing all libraries. Step 3 shows the solution: with entriesAware enabled, chunks are split by usage - a shared 8KB chunk for es-toolkit plus entry-specific chunks (195KB for dashboard, 40KB for admin, 63KB for landing), reducing average page load to 107KB and eliminating unused library downloads. Code snippet shows the configuration: entriesAware: true and entriesAwareMergeThreshold: 20000.
Chunks are now entry-aware in Rolldown 1.0.0-rc.5 ⚡
What does that mean? When grouping chunks via `codeSplitting`, they can now be automatically split per entry point (usually per page), so users download less unused JavaScript.
Just set `entriesAware: true`.
⚠️ Don't run it on every run though. Use it to audit your test suite, then clean things up.
Link to the docs for all the curious people
main.vitest.dev/config/detec...
Flaky tests and memory leaks are the worst.
@vitest.dev now has a flag that catches uncleared intervals, lingering servers, and other async operations leaking across your tests.
Available in the latest 4.1 beta. Big shout out to @ariperkkio.dev from the Vitest team for landing this PR! 🔥
Didn't try out Rolldown yet?
You should as it entered RC recently and is 10-30x faster while being compatible with Rollup's excellent API.
rolldown.rs
If you're a library author adding `@__NO_SIDE_EFFECTS__` to your code, know that your users will only see the full benefit with a bundler that understands it before splitting.
This matters for libraries like shadcn, Radix, or any component library using the annotation. Your route-level bundles can actually get smaller from it!
But @rolldown.rs handles this. It tracks which functions are marked `@__NO_SIDE_EFFECTS__` across your entire app. When it sees a call to one of those function, even from a different file, it knows the call can be safely dropped if the result is unused.
If your bundler only checks the annotation during minification, it's too late
The minifier only sees one file at a time
Which means it sees the call to the function but has no idea that this function was marked as side-effect-free before
🚨 The annotation does nothing exactly where it matters most!
Most apps use code splitting: Your code gets split into multiple files (chunks) to load less unnecessary JavaScript.
When that happens, the annotated function might end up in one file and the call to it in another.
Did you know about the `/*@__NO_SIDE_EFFECTS__*/` annotation?
It tells bundlers that a function has no side effects so every call to it can be tree-shaken if the result is unused.
Most bundlers and minifiers support it today.
But there's a nuance most people miss 👇
Why did adding ONE component make your build drastically slower?
The answer is often: Barrel files.
Luckily, you can enable Lazy Barrel Optimization in @vite.dev 8 and @rolldown.rs do bring your build time back to normal.
Want to know more? Check the video & docs
rolldown.rs/in-depth/laz...
"Expanding brain meme with 5 stages. Stage 1 (small brain): 'No tests'. Stage 2: 'Testing components by mocking document and window'. Stage 3: 'Testing with jsdom as fake DOM'. Stage 4: 'Testing with happy-dom because jsdom is too slow'. Stage 5 (galaxy brain): 'Testing in an ACTUAL browser with Vitest Browser Mode' with Vitest logo."
Tests.
Vitest's browser mode is stable since Vitest 4.0.
Now you can be sure that your tests pass in an *actual* browser environment.
vitest.dev/guide/browser/
Native plugins:
◆ @rollup/plugin-replace - Use `import { replacePlugin } from 'rolldown/experimental'`
◆ @rollup/plugin-dynamic-import-vars - Use `import { dynamicImportVarsPlugin } from 'rolldown/experimental'`
8 plugins replaced by zero-config built-ins or native equivalents.
