Rolldown-Vite

[sapphi-red]

Description

Current Status

• Vite repo test status
  • ✅ unit tests
  • e2e tests
    • ✅ external: changed the test for intended behavior change
    • ⚠️ legacy: some manifest related tests are skipped for now
    • ⚠️ object-hooks: parallel hooks does not run in parallel
    • ✅ resolve: skipped some browser field related tests as those cases were only supported by esbuild and Vite, also skipped some test that does fallback based on the file content which is Vite only and I believe it should not be done
• ecosystem-ci (see https://github.com/vitejs/vite-ecosystem-ci/blob/rolldown-vite/README-temp.md)

additional features

• tsconfig paths support (feat: add resolve.tsconfigPaths option to resolve with tsconfig paths #277)
  • When resolve.tsconfigPaths: true is set, resolution respecting tsconfig paths is supported
  • This option requires experimental.enableNativePlugin to be set to 'resolver' or true
  • Currently this feature only supports basic cases. If the tsconfig.json uses references/include/exclude, it won't work as expected.
• automatic emitDecoratorMetadata: true support (feat: enable decorator-metadata transform automatically #315)
  • Since Oxc supports emitDecoratorMetadata: true, rolldown-vite will enable that transform if it is enabled in tsconfig.json
• moduleType is supported in hook filters (experimental)

Intended behavior differences

• different import default from './foo.cjs' behavior (see https://rolldown.rs/in-depth/bundling-cjs#ambiguous-default-import-from-cjs-modules)
• esbuild needs to be installed manually in the following cases:
  • when using build.minify: 'esbuild'
  • when using a plugin using transformWithEsbuild function
• passing the same browser with multiple versions of it to build.target errors: esbuild selects the latest version of it, but that's probably not what you intend
• transformer: define does not share reference for objects oxc-project/oxc#7641
• require is never transformed into import, users needs to inject a polyfill on their own, see https://rolldown.rs/in-depth/bundling-cjs#require-external-modules
• build.rollupOptions.output.manualChunks is deprecated. please use build.rollupOptions.output.advancedChunks instead when possible.
• structuredClone(bundle) errors with DataCloneError: #<Object> could not be cloned.. please clone it with structuredClone({ ...bundle }) (Build errors with "DataCloneError: #<Object> could not be cloned." using rollup-plugin-webpack-stats #128)
• assigning to bundle[foo] in generateBundle hook is not supported. It is discouraged by Rollup as well.
• the bundle object reference is not shared across the hooks (manifest file not included in generateBundle hook bundle #410)
• (native plugin): if the package has both browser field and module field, the non-native resolver checked both fields and picked the one that looks like an ESM file. this behavior is not implemented in the native resolver as it was confusing and only legacy packages have this problem.

Known missing features

• output.format: 'system' ([Feature Request]: Support for System JS as output format rolldown/rolldown#2387)
• output.format: 'amd' ([Rollup Compat]: Support for AMD as output.format rolldown/rolldown#2528)
• native decorator support (transformer: ecma decorators oxc-project/oxc#9170)
• incomplete Typescript legacy namespace support (transfomer: Namespace variable updates not reflected inside namespace functions oxc-project/oxc#14227)
• shouldTransformCachedModule is not supported yet ([Feature Request]: shouldTransformCachedModule hook support rolldown/rolldown#4389)
• resolveImportMeta hook (Support resolveImportMeta hook rolldown/rolldown#1010)
• see [Tracking] native compatibility alignment for rolldown-vite plugins rolldown/rolldown#4973 for native plugin compat status

TODO list for me

• update docs

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vitejs/rolldown-vite@84

commit: 18e54bf

[christianjuth]

Found this PR in the Vite docs. Curious how stable rolldown-vite is. On a scale of "Next.js would call this is stable" to "this will actually work 99% of the time", were are we at?

[sapphi-red]

Found this PR in the Vite docs. Curious how stable rolldown-vite is. On a scale of "Next.js would call this is stable" to "this will actually work 99% of the time", were are we at?

I'd say it would work for basic cases as it is passing most tests through out the ecosystem.

[jclaveau]

Found this PR in the Vite docs. Curious how stable rolldown-vite is. On a scale of "Next.js would call this is stable" to "this will actually work 99% of the time", were are we at?

You can test it within minutes in your projects following this https://main.vite.dev/guide/rolldown#how-to-try-rolldown

In my case (using roughly 10 Vite plugins) the main blocking point was vite-plugin-legacy which doesn't work due to the lack of System JS output
I also had an odd Rust error while running the build more than one time (So it seems to be a cache issue).

But damn, the build is blazing fast!