Vite 5

[patak-dev]

We're starting a discussion to gather early feedback from the downstream ecosystem and users about their needs for Vite's next Major.

Before commenting, please review current open issues and check the previous Vite Major discussions:

• Vite 3
• Vite 4

Feel free to bring back proposals if you want to expand on them. If possible, create an issue for your feature and link it to this discussion so we can better track the proposal. For substantial changes to how Vite works, you may create an RFC.

Timeline

We've been aligning Vite's major releases with Node EOL. This year the Node team decided to move forward 7 months the EOL of Node v16, so we discussed with the Vite team, and the initial consensus is that it is better to skip the Node 14 EOL and release Vite 5 after September 2023-09-11 dropping support for both Node 14 and Node 16 (feedback welcome in case this affects your projects release schedule). Non Active LTS versions (Node 15, Node 17, Node 19) will also be dropped.

Node.js versions EOL

@lukastaegert, we're interested in the release schedule for Rollup. IIRC, you mentioned you wanted to start doing Major releases more often and aligning with Node EOL too. If there will be a Rollup major after the Node 16 EOL, we'll align with it. We can develop the alpha/beta for Rollup and Vite in parallel so we can release Vite after Rollup is out (how much we wait would depend on whether rollup introduces breaking changes to the plugin ecosystem).

As a tentative timeline, PRs and issues that require breaking changes will be added to the Vite 5 milestone during the next 3 months. Given that we will only have one Major this year, we could enter the alpha period for Vite 5 ~3 months before Node 16 EOL to give us time for more significant changes.

Initial thoughts

Vite has been focusing on a great performance story without compromising the flexibility of its rollup-based plugin API. We should double down on this vision. Work that improves performance should be prioritized for Vite 5. Some of this work may land in the next minors (see improvements to Vite's resolve logic at #12441, #12461, #12450). Vite 5 will give us a new opportunity to introduce breaking changes (that will probably be needed if we end up using Lightning CSS instead of PostCSS for example).

We've also been discussing moving vite-node (that now powers Vitest, Nuxt 3 Dev SSR, Histoire) to Vite core as an alternative to Vite current SSR primitives to add support for source maps and HMR during SSR. You can check out @sheremet-va's early work at #12165.

Check out the Vite 5 milestone, we'll keep it updated with new issues and PRs as we work towards the next Major. We're eager to hear your feedback and ideas.

[lukastaegert]

we're interested in the release schedule for Rollup

Considering the short timeframe between the two Node EOLs, I think I would follow you in skipping the first EOL for Rollup and also go for a new major in September. At the moment, I do not have anything "big" to release, and while I have some crazy ideas, time is very scarce at the moment, so going of the September release would improve the chances to have something releasable.

[patak-dev]

Sounds good. We can start to use Rollup alpha/beta as soon as you release them this time so we also help you better test the new Major. And even if there aren't big features by September, I think it is worth doing a Major release so you are free to use features from Node 18 after September when you see a good opportunity.

[shellscape]

an alternative view: there's no shortage of major version numbers, I don't subscribe to the view that major versions have to be big splashes. major versions can simply be a single breaking bug fix, regardless of project size.

So that we have continuity of conversation I'll share this here as well: we'll likely start rolling out updates to drop Node v14 support for https://github.com/rollup/plugins in the second or third week of May. We're a bit short on help so that's likely to take a while to get through all of the plugins.

[haikyuu]

Adding vite-node into core is huge 👍 We're using it in imba to bundle server code.

Another feature I'd love to see in core is Native support for tsconfig's paths resolution. We're currently using a forked version of a vite-tsconfig-paths that doesn't crash when no tsconfig file is present.

[nickserv]

FWIW, not even the TypeScript compiler fully supports path resolutions, and I've found it easier to maintain projects (especially libraries) without it.

[aleclarson]

RE the vite-tsconfig-paths fork, that issue was fixed in April:

aleclarson/vite-tsconfig-paths#97

[patak-dev]

We're discussing removing ssr.format: 'cjs' in Vite 5. Everyone in the ecosystem is using ESM for SSR as far as we know. Users could stay in Vite 4 for some months more if they need support for a CJS SSR build. We already marked this option as experimental in Vite 3 and added a note that this option isn't recommended and we're only leaving it to give users time to update. Let us know if you are using this option and what are the reasons preventing you to use Vite's default SSR ESM format.

[thebuilder]

I'm using Vite with https://github.com/JeringTech/Javascript.NodeJS - They recently added support for ESM in the latest beta, but it still had some issues executing Vite output. I should try again, and see if it's still an issue.

So still relying on legacy.buildSsrCjsExternalHeuristics: true

[patak-dev]

Please let us know how it is working now. I think a bit of friction and some projects staying in Vite 4 may be a fair price to pay to remove this complexity though. Maybe you could create an issue there explaining your problem so they are aware of it.

[thebuilder]

There's an issue here - JeringTech/Javascript.NodeJS#160

[brillout]

Related comment down below.

CC @nitedani @iMrDJAi.

[patak-dev]

Let's continue discussing removal of SSR CJS format here:

• Removing `ssr.format: 'cjs'` #13816

[TheRakeshPurohit]

The main hurdle I am facing is, migrating existing create-react-app projects due to node12 or older dependencies and react verisons. I am all in to update everything unless it breaks anything. Just need a stable support to port my entire app. Because the performance is the best in vite so far and want to continue that.

[snnsnn]

How is this related to vite?

[tjx666]

I think lib mode need to be enhenced:

1. support split assets, for now, all the images is inline as base64, check feat: allow assets to be external instead of inline in lib mode. #6267 and feat(vite): emitAssetsWithModule in library mode #9734
2. support auto inject css, ref plugin: https://github.com/marco-prontera/vite-plugin-css-injected-by-js

[moishinetzer]

or auto-bundling css on a module level would be incredible. Useful for those making component libs

[lefreet]

mark. a discssion here： #13617

[raulfdm]

Also this one: #10609

This PR has been there for 10 months already and solves a problem that no longer exists for cjs and esm since v3.something

[yzydeveloper]

Using rollupOptions might make it possible to:

rollupOptions: {
    preserveEntrySignatures: 'strict',
    input: '',
    output: {
        format: 'es'
    },
    external: option.external
},

[emosheeep]

here is a graceful way https://www.npmjs.com/package/vite-plugin-lib-inject-css, inject import statement at the top of each chunk file.

[manucorporat]

Better error reporting API! and fully annonated errors can be super nice, can try to put together a proposal for this!

[tjx666]

vite -d can't show the deep nested config props is a pain

[haikyuu]

very cool and useful idea. Is there an issue for this? @manucorporat

[rtsao]

I really love the continued emphasis on performance, great work! Looking forward to the release of the speed improvements to resolution 😃.

My number one wishlist item would be support for CommonJS in monorepo sub-dependencies. 📦 IMHO, this is by far the biggest footgun when using Vite today. CommonJS is ubiquitous in the npm ecosystem so users of Yarn/pnpm using SSR will almost certainly have issues. Users are presented with an unhelpful error message, so at the very least having a more helpful error would be great. While workarounds are possible, it's frustrating for newcomers and difficult to maintain the workarounds in configuration over time as dependencies are added.

• https://github.com/rtsao/vite-bug-repro-ssr-pnpm
• https://github.com/rtsao/vite-bug-repro-ssr-pnp

[brillout]

Related: #9367 which includes a proposal for how to handle linked dependencies.

[beeequeue]

I believe fixing file content hashing would make a huge difference for users, especially when migrating from webpack where this behaves differently and can potentially waste a massive amount of bandwidth having to re-fetch unchanged files

[volkandkaya]

Is this possible to add before v5?

[sapphi-red]

Just to make it clear, I think we will drop Node 19 as well.

[patak-dev]

Edited the post. Should we add a comment in the docs that Vite doesn't support Non Active LTS versions (odd-numbered) as soon as they become unsupported by node? As in not needing a Vite major to change this?

[sapphi-red]

That sounds good to me 👍

[TheRakeshPurohit]

yeah

[stafyniaksacha]

Maybe a better way to conditionnaly apply plugins ?

export default defineConfig({
  plugins: [
    !process.env.ENABLE_IMG_MIN === 'true'
      ? undefined
      : ImageMin({
        // ...
      })
  ]
})

[patak-dev]

Do you have something in mind? Falsy plugins are currently ignored so you can write the above snippet as:

export default defineConfig({
  plugins: [
    process.env.ENABLE_IMG_MIN === 'true' && ImageMin({ ... })
  ]
})

[stafyniaksacha]

This only prevents to keep plugin typing.
Small issue, but may be fixed with a helper function like defineConfig

[bengry]

Prioritizing fixing #2433 would be greatly appreciated. It seems to have started somewhere around v2.8.x or v2.9.x, and is effecting a significant amount of users from the reactions in the issue.

[clearfram3]

I've seen many comments related to the issues that different systems (esbuild, rollup) for development vs production builds cause. Has anything changed since the "Why Not Bundle with esbuild?" section on the website was made?

[hichemfantar]

This is my biggest problem with Vite, I get errors in prod that aren't present in dev which means I need to always test prod because it's not an exact replication of dev which slows down the entire release process.
Cra is slow but it doesn't have this problem.

[aleclarson]

The last time this question was asked, the docs explaining why ESBuild isn't used for production builds was updated to say this:

Vite's current plugin API isn't compatible with using esbuild as a bundler. In spite of esbuild being faster, Vite's adoption of Rollup's flexible plugin API and infrastructure heavily contributed to its success in the ecosystem. For the time being, we believe that Rollup offers a better performance-vs-flexibility tradeoff.

That said, esbuild has progressed a lot in the past years, and we won't rule out the possibility of using esbuild for production builds in the future. We will keep taking advantage of new capabilities as they are released, as we have done with JS and CSS minification where esbuild allowed Vite to get a performance boost while avoiding disruption for its ecosystem.

Vite is written to tightly integrate and therefore mimic Rollup's plugin API and all of its idiosyncracies. That said, I could see Vite migrating to ESBuild (though probably not this year or next, if I had to guess). I say this because my experimentation with writing my own ESBuild-powered bundler (whose plugin API takes inspiration from Rollup) has proven successful (for my admittedly narrow use case as of this writing). For my experimental bundler, it took a ton of work to achieve this, so I'd expect it to be at least somewhat harder for Vite (as migrating is often more painful than building from the ground up). Luckily, a package that eases this transition has spawned out of my efforts. Its name is esbuild-extra and it provides a transformation pipeline that ESBuild is currently lacking, among other things.

[iMrDJAi]

IMO, Vite 5 should restore support for CJS. Revert #11101, or provide a way to resolve CJS libraries with broken package.json exports. The JS ecosystem is not ready to fully drop CJS and move to ESM yet, the transition should be seamless.

[brillout]

Same opinion at #11299 (comment).

@iMrDJAi @nitedani Can you elaborate on why you still need CJS? AFAIK ESM should always be able to import CJS packages.

[iMrDJAi]

@brillout I don't need CJS, but I depend on libraries that are published in CJS format. CJS packages can be imported in ESM projects, but the ones with broken package.json exports no longer work. They used to work fine before Vite 4.

[brillout]

CJS packages can be imported in ESM projects, but the ones with broken package.json exports no longer work. They used to work fine before Vite 4.

Can you elaborate on that?

Making Vite always output ESM code is an import and foundational move. We shouldn't have any blind spots around this.

[clearfram3]

@iMrDJAi if they are broken shouldn't they be brought up to the current, correct standard instead of bending the tool?

[nickserv]

Vite already compiles CJS libraries (like React) to ESM, so I don't think this is an issue.

[nitedani]

I would like Vite to have built in support for building node_module-less ssr (only node builtins are externals). Just like next and nuxt does. For this a replacement for https://github.com/vercel/webpack-asset-relocator-loader would be needed.
This loader handles node_module-less bundling for libraries like Prisma, sharp, etc... by relocating .dll,.so,.node,.js files to the dist folder.
This feature is the only reason I'm still using webpack to bundle Vite's ssr build output into a single, node_module-less folder. This way I don't need to install the huge node_modules in each of the dockerfiles inside the monorepo, but only copy the dist folder.

[yArna]

Any ideas for improving Page reload very slow?

#13697

[bluwy]

Putting here some Vite 5 todos I'd like to work on:

1. Fix fix: unoptimized package can resolve to optimized deps #11410, Monorepo project dedupes dependencies even when not specified #9948
2. Externalized SSR deps should not have _esModule interop in dev (inconsistency)
3. ?url&inline=true/false support
4. Make esbuild transpiling target based on tsconfig.json, then fallback to esnext.
5. fix: exclude external dependencies from html rewriting #11854

[bitsnaps]

Any news about Vapor Mode on Vue3, can this feature be implemented into Vite by design as an argument option or better a plugin?

[mbokil]

You will probably get better responses to Vapor mode on the Vue Git site. Latest news I read is to tentatively expect it to arrive by the end of the year.

[qiyongjin]

What I need is a vite package to put index.html into... /.. /templates/delivery/
Inside this directory, then put the other static files js/css/assests into... /.. /.. /static/delivery/, whether the requirement can be implemented

[zhanglolo]

I want a feature that package project css into one file, exclude dependecy css, like build.cssCodeSplit.
In general, CSS files in a project are usually small but numerous.

[jeron-diovis]

Get css modules fully working
#10340
It's a major breaking point when migrating from create-react-app.

[AsuraKev]

I would like vite to have official built in support for module federation :)

[AsuraKev]

current vite competitor - Rspack (Webpack 1.1 is in progress and will be released to webpack and Rspack). If this feature is implemented in vite it ll be awesome

[kenilam]

I would like to resonate with that. And top of that, if MF could finally be possible in dev mode.

[an501920078]

That's a good idea

[ghiscoding]

is there a pre-migration guide to Vite 5 even if it's still in Beta? I would like to start testing it with my projects but I don't feel like reading through all breaking change PRs to find out what changes are required. Thanks

[bluwy]

Yes you can check it at https://main.vitejs.dev/guide/migration.html

[yzydeveloper]

What is the performance gain of using rollup@4 in the vite@v5.0.0-beta.10 version compared to the previous rollup@3 version? Do you have any test? @sapphi-red

[probablykasper]

Fixing #8237 would give a 100x dev server page load performance boost to people that use icon libraries. With tabler-icons, page load/navigation takes 30-60s and build times increase by ~20s

[gsipos]

Hello!
After installing Vite 5 I get this TS compilation error:

node_modules/vite/dist/node/index.d.ts:6:41 - error TS2307: Cannot find module 'rollup/parseAst' or its corresponding type declarations.

6 export { parseAst, parseAstAsync } from 'rollup/parseAst';
                                          ~~~~~~~~~~~~~~~~~


Found 1 error in node_modules/vite/dist/node/index.d.ts:6

Since it's coming from inside Vite, setting skipLibCheck: true in tsconfig.json makes it go away, but I'd prefer to keep that flag turned off.

[bluwy]

You need to use moduleResolution: 'bundler' (or node16/nodenext) to fix it. Rollup only export those types from the "exports" field which those resolution settings respect.

[gsipos]

Worked like a charm! Thanks! 🙏

[virtuoushub]

Hello, after upgrading to 5, I needed to add --expect 404 to be able to continue to use start-server-and-test as expected (worked in 4.5.0).

Any idea why this is now necessary? My best guess was something related to https://vitejs.dev/guide/migration#align-dev-and-preview-html-serving-behaviour but that was just a shot in the dark.

See also: bahmutov/start-server-and-test#294 (comment)

[bluwy]

This is fixed in #15025 and will be released in the next patch (5.0.1)

[emosheeep]

Is there a way to restore the behavior how the previous version of vite process module styles, reserve default export of the style files that without a module extension? Because there's a large amount of legacy code which can't be migrated easily. 😖

[anranlee99]

Pressing o in the terminal no longer opens up the deployed link. Is there something I can do to get this back?

[chadallard]

Pressing "o" does work for me, but now I need to press Enter before the commands work. Same for "r". In the past you could simply press the key in terminal and it would perform the action.