Roadmap

[yyx990803]

This roadmap outlines the high-level milestones that we intend to follow as we progress with Rolldown's development, but is subject to frequent adjustment as things go.

Milestone 1: Basic Bundling

• Goal: to be able to use Rolldown instead of esbuild to perform dependency pre-bundling in Vite.
• Key features needed:
  • Basic code splitting for multiple entrypoints
  • cjs / esm mixed bundling
  • Basic plugin support

Milestone 2: Advanced Bundling

• Goal: to be able to use Rolldown for production builds in Vite.
• Key features needed:
  • Treeshaking
  • Basic CLI & config file support ^{by @kazupon}
  • Source map ^@underfin
  • Chunk hashing ^@hyf0
  • General Rollup plugin compatibility (90%) Tracking issue
    • Note: we are currently not focusing on 100% compatibility because there are many APIs that are very niche and rarely used. Instead we are focusing on implementing enough compatibility to run as many commonly used plugins as possible. Most official Rollup / Vite plugins are either already compatible or not needed anymore.
  • Advanced chunk splitting ^@hyf0
  • Built-in CSS bundling ^@hyf0

Milestone 3: Transform Features

• Goal: to be able to use Rolldown for all current esbuild usage in Vite.
• These features will be relying on oxc which is developed in parallel to Rolldown. We want these integrated in Rolldown so we can reuse the same AST as much as possible.
• Key features needed:
  • Built-in Typescript / JSX transform (via oxc)
  • Built-in minification (via oxc)
    • Only integration is completed; Oxc minifier is not production yet.
  • Built-in Syntax lowering (via oxc)

Milestone 4: Behavior Alignment

• Behavior alignment for both esbuild and Rollup
  • enable all esbuild tests
  • improve esbuild test coverage
  • enable all Rollup tests
  • improve Rollup test coverage
• Port perf-critical & eligible Vite internal plugins to Rust
• use oxc-resolver by default

Rolldown 1.0 beta after Milestone 4 is hit

Milestone 5: Rolldown-powered Vite

• Fully replace esbuild and Rollup in Vite
• Pass all relevant Vite tests (known issues))
• Pass Vite ecosystem CI (26/28) ^WIP
  • Note: Astro / Histoire support are on hold for now as we focus on production stability for SPAs for now

Rolldown-Vite preview release after Milestone 5

Milestone 6: Vite full-bundle mode

Use Rolldown bundle for dev (eliminate optimizeDeps)

• Rolldown built-in HMR support
• Incremental build
• Full bundle mode via --full-bundle for SPA

Quarterly Plans

• ☂️ Plan for 2025 Q4 (Oct - Dec) #6210

Side Features

Don't fit in a specific milestone but good to be tackled whenever possible, likely after Milestone 4.

• WASM build performance issue
• Module Federation [Tracking] Module Federation #5469
• DTS generation + bundling via rolldown-plugin-dts
• Opinionated, zero config TypeScript library bundling (see tsdown)
• Built-in profiling / build observability (docs soon)
• Output size optimization (parity or better than Rollup / webpack / rspack)
• Playground (https://repl.rolldown.rs)
• Built-in bundle analysis (WIP via Vite Devtools)

[kazupon]

@yyx990803
I have a question.

I found out vite-compatible open source project called farm, which is implemented in Rust.
That is similar to rolldown's goals, does rolldown have any plans to collaborate?

https://github.com/farm-fe

[yyx990803]

The problem with Farm is that it is designed more like a complete build tool like Vite, instead of a lower-level bundler that supports it. This makes it difficult for us to envision a future where it can be integrated into applications using Vite today. We've talked to the author previously, I think there might be a chance to have him collaborate on Rolldown in the future.

[sanbei101]

The collaboration is truly wonderful

[montoyaaguirre]

Congrats on the progress so far 💪

I remember that you addressed the lack of first party module federation support during your 2023 keynote "The State of Vite".
Will this be worked on during one of these 4 stages?

[alexandersorokin]

I think there is no necessity to implement module federation support. It isn't required in the modern world.

Native es modules is enough to load microfrontends (via dynamic imports) and share common modules (via CDN like esm.sh). Module federation doesn't provide a better way of doing that. Native es modules are simpler, more robust, work even without bundlers.

I am sure that module federation should be considered a legacy. So introducing support in codebase looks like making tech debt.

[husayt]

As someone who has worked on some of the largest frontend solutions in banking and finance I can say, that lack of Module Federation support is number one (and only) reason why Vite adoption in major banks is slower than elsewhere. Microfrontends are necessity pattern for building modern enterprise software and Module Federation is the most popular pattern and thanks to extensive examples, support of edge cases and rich documentation is much more established than Native Federation and other variations.

[leookun]

vite is designed as native ESM, try using ESM in your code like : import something from "another vite server"
That's simple and efficient module federation

[maliknajjar]

You cant import .svelte files like that. You need to compile them first. This is one example why we need vite MF

[vekunz]

vite is designed as native ESM, try using ESM in your code like : import something from "another vite server" That's simple and efficient module federation

import something from 'remote url' is not allowed in Node.js (e.g. for Server-Side Rendering), so Module Federation is a must-have

[benmccann]

Exciting! I'd love to try it out soon. One thing that would be great is some sort of repl / playground like rollup, esbuild, and oxc have

[yyx990803]

There is a already a playground in place but we need to fix a few issues to get the wasm build working.

[TheAlexLichter]

The playground is available now (for a while, but updating in case some of you swing by again)!

[NMinhNguyen]

Is "bundled" mode meant to be on the roadmap as well? See https://twitter.com/youyuxi/status/1730412728333025635?s=46 for context. Or more specifically https://x.com/youyuxi/status/1730855549863178698?s=46. It's common to have packages in a monorepo that export lots of code from a single entry point (instead of requiring deep imports into the package which would sort of work like manual tree shaking). In my app, I was hoping to make use of lazy loading to help with unnecessary modules getting loaded, but importing just a single thing from a fat monorepo package ended up pulling in everything 🥲

[yyx990803]

Yes, added it to the last milestone.

[Dooblr]

One pain point with Vite+Rollup currently is using libraries that require polyfilling and resolving Node global variables like Process, Buffer, Crypto, etc.

We have some dependencies that worked fine with Webpack polyfill plugins but spent a fair amount of time working on implementing Vite & Rollup plugins, aliases, and updating our own libraries to make it work.

If this seems like something worth addressing I can provide specific examples.

[yyx990803]

Our general stance is that it's bad practice to rely on Node globals when you are targeting browsers, so it is intentional that we don't provide this as a core / default feature in Vite in order to push new users away from dependencies that do this.

For users migrating from old codebases that already have such dependencies and can't easily migrate away, there are already community solutions: https://www.npmjs.com/package/vite-plugin-node-polyfills

For Rolldown, the community plugin should continue to work so it won't be high priority. But it should be trivial to have this ported as a Rust native plugin and become a built-in option, if necessary.

[ianzone]

Does Rolldown plan to support building Node projects like Nestjs? Rspack supports that btw https://rspack.dev/guide/tech/nestjs

[zhang2657977442]

What is the difference between Rolldown and Rspack

[zackarychapple]

Rolldown is the rust rewrite of Rollup
Rspack is the rust rewrite of webpack

[OskarLebuda]

What about the HMR? As I know the HRM not exists in rollup at all. Will Rolldown supports this feature from the beginning out of the box? Or it still will be esbuild?

[OskarLebuda]

@yyx990803 ? :)

[benmccann]

I don't think HMR and esbuild have anything to do with each other in Vite currently

[craigrileyuk]

HMR is a feature provided by Vite itself.

One of the major reasons for developing Rolldown was because HMR used esbuild and production used Rollup and they wanted to use the same toolset for both.

[TheAlexLichter]

HMR will be is already built into Rolldown itself.

[franmc01]

I love that this considers Module Federation, but you know that I also see it as necessary, something solid that brings out the best of vite to integrate with Single SPA

[zackarychapple]

@franmc01 have you been able to use it in production? Would love feedback.

[trickpattyFH20]

@zackarychapple

I am using this one in production: https://github.com/originjs/vite-plugin-federation

It has some bugs. One particularly annoying bug is related to duplication of the React source being shared between remote and host with React versions > 17.

I haven't hit any critical blockers with it so far, but I'm still very eager to get first party support for module federation in Vite.

Thanks for putting it on the roadmap!
@yyx990803

[Nimith-M-Gowda]

https://github.com/originjs/vite-plugin-federation doenot support redux toolkit, isn't it ?, am facing issues !

[anajnas66]

Also it doesn't seem to work with Remix. Looks like it has quite a lot of issues.

[zmzlois]

does this work for you? @anajnas66 @Nimith-M-Gowda https://github.com/module-federation/vite ?

[benmccann]

I thought I'd mention that for milestone 3, the team here might need to help contribute some improvements to oxc before switching to it for minification. I did a bit of testing between oxc and esbuild and found that esbuild produces smaller output today. The oxc team stated that they currently don't have the bandwidth to work on minification and closed my issues, so I'm guessing the gap won't get closed without some efforts from this side. oxc-project/oxc#2646 for reference (note that in this issue esbuild does not produce optimal output either, but there are others where esbuild excels relative to oxc)

[yyx990803]

We are working closely with the oxc team and already contributing to oxc (e.g. recent sourcemap optimizations).

[ghost]

A minifier is mentioned in oxc website as one feature they want to implement.

At the same time, CSS processing by leveraging Lightning CSS is considered in the development of rolldown.

As I understand, you plan to develop CSS minifier and CSS transformation in rolldown with lightningCSS, while resorting to oxc for minifying and transforming JavaScript. Is that correct?

[yyx990803]

That is the current plan, yes.

[trymeouteh]

Will the css bundling be done by having a CSS entry file such as index.css, or will be done using a JS entry file such as index.js using import method?

[BitTechDeveloper]

will you provide the feature to preserve the complete folder structure between src/ and dist/ in rolldown by default with any required configuration?
I mean if I've 4 to 5 level nested folder structure in src/ for html css js and images and I want this to retain in my dist/ exactly and want this to be default behaviour so I don't need to configure anything,
will you porvide this feature when rolldown becomes the underlying technology for vite?

[hyf0]

It' might be better that you explain your requirements in more details.

• Does other bundler supports your needs?
• What's the context?
• How is it useful?

[BitTechDeveloper]

Other bundlers I tried doesn't support this feature except vite. but it support it for only html files. and mostly it's enough.

the main context is url structure issue in multipage application. for example in development we organise files in src/ according to url structure need but when we build, it all goes in the same folder in dist/ this way we can't control the url structure for individual files, but that's not the case for vite and I'm glad vite solved this.

It's also useful when we need to manage some small but distinct project in the same repository because creating a separate repository for each small project is headache.

for other assets like css js and image it does't matter a lot but it would better if we have this feature too.

[EAGzzyCSL]

This feature is called preserveModules in rollup. I like this feature.

[oliveirakennedyjoao]

I don't want to exercise or charge anything in relation to this initiative, but I have a real interest in using it, especially due to the support for module federation. Is there any prediction on when it will be released? I only ask to plan myself for the future.

By the way, Congratulations on your progress so far.

[zackarychapple]

you're not alone :)

[pcfreak30]

Ditto to this. I am following https://module-federation.io/, but as it comes out of webpack and im using remix, the hard-wired integration makes it not practical to switch tooling. So need to have the ecosystem upgrade to vite with rolldown.

[AustinGrey]

He Yunfei mentioned on the discord that the current target is to be feature complete this year. Whether that includes module federation or not is unclear, and of course as an open source project with volunteer work and donation based support any kind of deadline is fuzzy at best.

[OskarLebuda]

@yyx990803 how about the TypeChecker?
The problem since the begining of the Typescript is the type check process. This process takes long time on every large projects. Maybe you should consider TypeChecker written in rust inside of OXC or Rolldown directly?

[yyx990803]

No type checking planned due to exactly what @overlookmotel explained.

One thing that may help with type checking speed though, is dts emit based on isolatedDeclarations. This allows dts to be generated by a transformer like oxc without going through tsc itself. This has a few implications:

• type-checking based on the generated dts instead of TS source is significantly faster
• isolatedDeclarations also enforce more explicit annotations in types, which reduces type inference overhead
• Larger projects (monorepos, project references) can generate dts of all packages really fast AND in parallel

This is a more realistic way to improve TS type checking performance and oxc already supports the isolatedDeclarations transforms. Rolldown plan to provide built-in dts emit + bundling for TS codebases that are isolatedDeclarations-compliant.

[ghiscoding]

Side note the isolated declarations that Evan mentioned, was released not long ago in TypeScript 5.5, see their blog post Isolated Declarations section for more info. They do mention that it's very new and it won't show a huge perf yet but it will be improved in feature releases

Note that isolatedDeclarations does not change how TypeScript performs emit – just how it reports errors. Importantly, and similar to isolatedModules, enabling the feature in TypeScript won’t immediately bring about the potential benefits discussed here. So please be patient and look forward to future developments in this space.

[nrayburn-tech]

While not something coming from Rolldown/Oxc, Microsoft is rewriting some (all?) of the TypeScript compiler in Go. This is expected to come with some pretty noticeable performance impact for end users.
https://github.com/microsoft/typescript-go

[Bricklou]

While not something coming from Rolldown/Oxc, Microsoft is rewriting some (all?) of the TypeScript compiler in Go. This is expected to come with some pretty noticeable performance impact for end users.
https://github.com/microsoft/typescript-go

Be careful, this isn't a rewrite, this will be a port. Which means the code will just be transposed into Golang without further optimisation. So all the gain of performance will only be related to the runtime change.

[J3m5]

While not something coming from Rolldown/Oxc, Microsoft is rewriting some (all?) of the TypeScript compiler in Go. This is expected to come with some pretty noticeable performance impact for end users.
https://github.com/microsoft/typescript-go

Be careful, this isn't a rewrite, this will be a port. Which means the code will just be transposed into Golang without further optimisation. So all the gain of performance will only be related to the runtime change.

This is not entirely accurate. While it is a port rather than a full rewrite, there have been optimizations beyond just the runtime change.

One key improvement is Go’s built-in concurrency model, which enables parallelized type checking thanks to efficient shared memory access. This alone accounts for a significant portion of the performance gains.

[MadaraUchiha-314]

@yyx990803 I created a rollup plugin for Module Federation: rollup-plugin-module-federation and it has support for Module Federation 2.0 and uses the latest runtime and sdk packages exposed by https://github.com/module-federation/core

Have been collaborating with Zack J (creator of federation) for the since the past few months on this!

Would love to implement Module Federation in rolldown as well!

CC: @zackarychapple

[pcfreak30]

Kudos on this. Might give me an opportunity to implement this in my project before rolldown. Though I would like to see MadaraUchiha-314/rollup-plugin-module-federation#51 merged if only to ensure vite 100% works.

[zhangHongEn]

I recently spent a week to complete the vite plugin. Most of the plugins could not be completed because they could not adapt to the pre-built dependencies of vite dev mode. I PR it here
module-federation/vite#4

[jloa]

That plugin still has issues with improper resolution of exports aliases (those are treated as dif deps) also it can't handle circular deps

module-federation/vite#172

[zhangHongEn]

Currently, the main features of module-federation 2.0 are working fine, especially the manifest.json, which significantly improves performance. I’ll need to find time to fix the non-critical issues.

[fulme]

Are there timelines related to each milestone? @yyx990803
My job requires me to rely on this to make some long-term plans.

[yyx990803]

Our estimation is beta status by EOY 2024.

[jloa]

Same here, we are currently torn between rspack with decent federation vs vite + federation crutches. Looking forward a decent out of the box implementation of federation in vite

[zackarychapple]

@jloa we are working to help make this a reality. Vite + Rolldown support will be pretty awesome. This is just the start #153 (comment)

[heggria]

I'm particularly curious whether the performance of Vite+Rolldown (e.g., startup time and build speed) would show a noticeable improvement over Rsbuild, especially considering that Rsbuild now claims dev performance that's 3x faster than Vite+SWC and build performance that's 5x faster.

[IWANABETHATGUY]

rsbuild claim they are 3x faster than rollup+vite, swc is just used for transform, the benchmark of rolldown-vite is here https://github.com/rolldown/performance-compare-ext

[zackarychapple]

Thank you for updating these benchmarks @IWANABETHATGUY! Something that I think would be great would be to pull a page out of Apple's book and compare against previous iterations of Void0 products as well. For example I'm just as interested in seeing Vite + Rolldown + OXC vs Vite + Rollup + OXC. Also iterations of Rolldown + Vite would be great to see.

[IWANABETHATGUY]

Thank you for updating these benchmarks @IWANABETHATGUY! Something that I think would be great would be to pull a page out of Apple's book and compare against previous iterations of Void0 products as well. For example I'm just as interested in seeing Vite + Rolldown + OXC vs Vite + Rollup + OXC. Also iterations of Rolldown + Vite would be great to see.

Thanks for your advice.

[curlykay]

According to the Roadmap, oxc-transformer will handle the built-in syntax lowering in rolldown. I have some questions that might help me plan ahead:

Will rolldown's built-in syntax lowering include built-in API polyfills?
What's the lowest ECMAScript version that rolldown's built-in syntax lowering will support? Is syntax lowering to ES5 supported?

[IWANABETHATGUY]

You could ask the question in oxc discussion, IIRC for current milestone, lowering to ES5 is not included, However, I am uncertain whether it will become a goal in the future.

[Boshen]

built-in API polyfills

What is this?

Is syntax lowering to ES5 supported?

Why do you require to lower to es5?

I need more context for prioritization.

[curlykay]

For example, does syntax lowering automatically add polyfill to api's like Promise.withResolvers, this is questioned because I was under the impression that syntax lowering and polyfill were the two aspects of achieving compatibility with lower versions of the front-end environment.

The doubt about being able to downgrade to es5 is due to the fact that some of my long time clients are still using custom browsers with chrome <50 versions and I don't have the power to make them upgrade, which is a bummer, but it's something I've had to consider.
I'm currently using vite+swc to build the es5 version of the program, and if rolldown's built-in syntax lowering is supported up to es5, I'll be able to cut out the swc dependency.

[curlykay]

Please don't feel any pressure to commit, my question is just to have an expectation in advance. You guys have been on the front lines of working to improve the front end environment🫡

[chioio]

Why would u want es5 in the modern toolchain? Yes, modern toolchain...

[chvanam]

Related to the WASM build side feature, that recently got tweeted about by Evan:

• Could there be any plans to allow vite itself to be run in a WASM/browser environment?

This idea already exists as a fork (browser-vite), but with Vite's new Environment API, and this future bundler, we could make this easier. It would require the following:

1. Implement a browser-specific Vite Environment:

   • Virtual filesystem support (could map to the browser's File System API, or a real FS) (this is already supported in rolldown I believe)
   • Browser-native dev server (probably iframe-based HMR using postMessage API)
   • Minimal Node API surface emulation in this environment (path, fs, etc.), with warning if we (or dependencies) trespass them

2. Adapt Vite's core to be environment-agnostic:

   • Move Node-specific operations behind the Environment API (we could have an official node enviroment, but other runtimes could do optimisations for a faster DX such as deno or bun, instead of relying on their node compatibility)
   • Replace direct fs/path usage with environment abstractions
   • Handle browser-specific limitations (like file watchers)

The WASM build feature of Rolldown is great, however its primary use cases (presented in the tweet) of browser coding environments like StackBlitz rely on proprietary WebContainers technology.

I'm interested in opinions about this 🚀

[falldowngoboone]

Is it safe to assume the Rolldown team will not be implementing native federation support in favor of the Module Federation team's plugins? I ask because my team is planning on a transition to micro frontends, and since we're already on Vite, we were excited to learn that Rolldown may have native support. After reading through these discussions, though, I'm less clear on what Rolldown intends to do.

Personally, I think it makes more sense to allow the Module Federation team to take on the effort to support federation in Vite (and Rolldown transparently) since they're closer to the problem space. That frees up Rolldown to do what it does best.

[eslawski]

@zackarychapple Can you talk a little bit more about how the @module-federation/vite plugin differs from module federation plugin that the rolldown team is working on?

[zackarychapple]

@eslawski for sure. The one in @module-federation/vite is currently a community plugin that is mantained mostly by @gioboa and works really well. That being said @underfin, @Boshen and @yyx990803 added formal Module Federation support directly to the bundler itself. This gives us a much easier to maintain path for Module Federation at the bundler level rather than the community plugin level. If you have specific questions or a use case you're evaluating happy to discuss here or on discord or X.

[vekunz]

A comment to Native Federation: Recently, we evaluated micro frontend technologies for a new project. And we concluded that Native Federation is basically dead. There is no plugin for Vite anymore, the maintainers are only maintaining it for Angular with webpack, there is no official documentation, no website, yeah not even the source code is public! Therefore, we decided to use Module Federation.

[TheAlexLichter]

Update in terms of module federation: The old & faulty implementation that existed in Rolldown was removed. We want to tackle it after full bundle mode. Please follow this tracking issue for updates ☺️

[zackarychapple]

Welcome to MF land @vekunz.

[trymeouteh]

Is Rolldown planning to also support CSS, allowing you to...

• bundle CSS stylesheets
• generate sourcemaps (map files, inline sourcemaps)
• minify CSS
• watch for changes made to CSS files

I noticed some pull requests on CSS sourcemaps.

LightningCSS does all of these things except for watch for changes and inline sourcemaps

[hyf0]

Yes. They are all planned. Currently we are focusing on HMR and incremental build support. Once there are done, we will review our bandwidth on css support.

[ianzone]

A "keepName" option for the minifier is needed. It's useful when building doc sites while the sites need to display source code.

[IWANABETHATGUY]

try keepNames https://stackblitz.com/edit/github-w6djypys?file=dist%2Fother-entry.js

[DylanPiercey]

Is the playground related code available anywhere? Also regarding exposing a virtual file system for this repl is this something that will be officially supported? I ask because it'd be cool to use this rolldown to build other repls, however other tools like esbuild don't make this easy as their repl uses private apis.

Edit: oh I guess its this #153 (comment)

[rafabmr]

@yyx990803 Time for an update?

[yyx990803]

Just updated!

[coclip]

It looks like it's getting close to being production-ready!

[refinist]

👀

[jamesopstad]

I see "Full bundle mode via --full-bundle for SPA" on the roadmap. Will full-bundle mode also be implemented for server environments? This also has significant benefits.

[TheAlexLichter]

Yes, a full bundle mode for server environments is on the list, but further down the roadmap (after Rolldown 1.0).

[jamesopstad]

That's great to hear! Let us know if there's anything we can do to help push this forward.

[TheAlexLichter]

Will do! 👍🏻

[sixdjango]

It is expected that a stable version will be released in a few months?

[abandon-jw3]

When's the stable version expected? I'd love to use it in production, but my boss says no to betas.

[refinist]

When's the stable version expected? I'd love to use it in production, but my boss says no to betas.

Use rolldown-vite

[yyx990803]

We are now pretty confident in the general stability of Rolldown (Framer just shipped Rolldown for all their production bundling) and have only a few items left on the roadmap. But before we release Rolldown as stable, we will need a bit of extra time to (1) polish and improve documentation and (2) strengthen our ecosystem testing / regression tracking to ensure better stability in future releases.

An estimated (but not guaranteed) time for 1.0 stable is early 2026.

[refinist]

I'm quite interested in Module Federation and looking forward to it.

[TheAlexLichter]

@refinist Feel free to subscribe to #5469 for more updates! Rolldown will have MF eventually but the priority is on finishing full bundle mode at the moment.

[refinist]

@TheAlexLichter I've been following it closely 😬

[shairez]

@TheAlexLichter hey long time buddy! 😊
say, is there a design doc or RFC for "Full bundle mode"?
Would love to learn more about it, sounds like a very much needed feature indeed

[TheAlexLichter]

@shairez Hey 👋
We are working on a more clear description & overview for the public as we speak 👍

[shairez]

Thanks! Can't wait to see it! 🙌