Vite 4

[bluwy]

With Rollup 3 released, we will be starting Vite 4 alpha/beta soon to bump the internal Rollup version. Along with other changes in the v4 milestone.

This release is planned to be less breaking, so not much work should be needed to upgrade. Among the main goals for this major release are:

• Rollup 3 (feat: rollup 3 #9870)
• Full es2020 compatibility. Support BigInt. (Full es2020 compatibility by default #9062)
• Upgrade dotenv (Support for Multiline values in env files #10149, feat(env): support dotenv-expand to contains process env #10370)

Some cleanups:

• Improve file serving (Vite strips base URL from request #9234, Ability to serve base page without trailing slash #9236, feat: handle static assets in case-sensitive manner #10475)
• Simplify mode and env var handling (Rethink dev/prod/mode handling #9274)

If you have any feedback about Vite 4, especially regarding breaking changes that we will not be able to do in future minors, let's discuss this here or create an issue and link it to this discussion.

[yann-combarnous]

Any chance to get #9590 added as part of Vite 4? Switching jsx automatic transform to esbuild should bring a nice performance boost for React developers.

[patak-dev]

There are unaddressed requests in the PR, but once they are done, we could release a new major of plugin-react independent from Vite core. I think it is still better to try to bundle the releases but changes to plugins can't be applied when they are ready.

[polRk]

Will the module federation be present?

[bluwy]

We don't have plans for first-class support yet, but there is a Vite plugin you can use now too: https://github.com/originjs/vite-plugin-federation

[fantasticsoul]

you can also try hel-micro
a codesandbox demo: https://codesandbox.io/s/demo-load-remote-vue3-comp-2fd34s?file=/src/main.js

[tjk]

I would love to give more feedback on vite 3 (and vite 4) but unfortunately am still stuck on vite 2 (like many others?).

Is any active work going into the most upvoted issue: Vite build: out of memory -- #2433

When disabling sourcemaps, I get stuck later on the build with this issue: Duplicate module bundles when optimized dependencies are reloaded during build -- #9171

[bluwy]

We would need some help on identifying the memory issue for #2433 as it's a broad topic. We had a brief discussion with Lukas from Rollup and have a hunch that it's caused by Rollup's module graph being kept entirely in-memory for tree-shaking. This may be improved in the future from Rollup instead, but another potential candidate to improve in Vite is #1309

[tjk]

+1 to #1309 -- rebuilding monaco-editor, etc. every time is such a waste and I think it's a common package amongst many people in that issue.

[Kiprotich400]

Personally I love anything latest. So am in 4 already. Works really good.

[Rich-Harris]

My biggest wishlist items for Vite at the moment are #9378, #7887 and #2830. Of those, the only one that I think could be considered breaking — and therefore worth prioritising for a new major version — is #9378. I would argue that the current default behaviour around clearScreen doesn't make a whole lot of sense, and it's certainly a common source of frustration (I often find myself wrapping console.log statements in setTimeout with arbitrary delays).

[rtsao]

Not technically a breaking change, but I'd love to see #9763 landed. At the moment, Vite SSR will crash if you are using a pnpm or Yarn monorepo and have any CJS dependencies.

[lovetingyuan]

What is the time to support http2 with using proxy by default? I think it is important for loading performance.

[bluwy]

This is also discussed in Vite 3 #7611 (comment), but the results seems to be that there wasn't much performance difference. I think it would still be better in the long run to move to http2 though, PR welcome!

[harshareddyp4]

generation of type decalarations in dist folder in library mode without any flags or plugins

[Shinigami92]

As far as I know, for this we would need to include whole typescript dependency in Vite's core which would blow up the package size.
Most folks using Vite are using it for bundling Frontends where types are not needed.
So it is a really good trade for use to have vite-plugin-dts, to cover types for lib mode.

Here you can see a dependency graph of that plugin: https://npmgraph.js.org/?q=vite-plugin-dts
And you will see that it depends on @microsoft/api-extractor which brings typescript and a lot of other stuff.
Vite only has @microsoft/api-extractor only as a devDependency.

vite/package.json

Lines 38 to 40 in f787a60

	"devDependencies": {
	"@babel/types": "^7.19.4",
	"@microsoft/api-extractor": "^7.33.4",

So I'm sorry, but your request will never happen.

[tajo]

Browsers can get pretty slow when a project has lot of modules which results into a lot of http requests.

Not sure what the best long-term approach is but it would be nice to address this #10047 so optimizeDeps.include can be used to pre-bundle workspaces and their deps to cut the number of http requests.

[moosemanf]

We also experience major problem with the modules, browser (in dev) has over a minute in pending for all those http requests.

we rebuild a lot of stuff to be more lazy, but I was thinking about the http-server that is used... is there a better, more performant substitute? it seems that the simple amount of requests puts the server under so much distress, that it just takes forever to resolve the first requests

[benmccann]

It's unlikely to be related to the http server being used. It's hard to understand what exactly the issue is in your case without a reproduction though

[moosemanf]

I did not realize that v4 is already out in the wild, and I'm happy to report that our issue with pending requests and waiting long times for the first render in the browser is gone with this version!!

[typhonrt]

As far as my wish list for Vite 4 is concerned... I'm still trying to figure out what is going on in Vite 3 regarding a lib production bundle and tree shaking not apparently working. For reference #8464 is tracking this issue w/ Vite 3. Even adding the specific Rollup parameters mentioned in that issue doesn't seem to be effective w/ my UI library / end developers setups. Coming from Rollup before Vite 3 this wasn't a problem.

With moving to Rollup 3 for Vite 4 making sure tree shaking works for production builds (lib or otherwise) out of the box would be superb. Thanks all Vite devs / maintainers!

[typhonrt]

Just as a note after spending a bit more time w/ Vite 3. It appears what is happening with my Svelte UI framework / library when creating distribution bundles is that all the CSS from every Svelte component from the UI library is getting included / no tree-shaking for the CSS from each Svelte component even if that component is not included in the final build. This is related to issue: #4389

[aslanalyiev]

Dependency pre-bundling only applies in development mode, and uses esbuild to convert dependencies to ESM. In production builds, @rollup/plugin-commonjs is used instead.

Give the possibility(option) to use esbuild instead of @rollup/plugin-commonjs during the production build.

[tjk]

Have you seen this? https://vitejs.dev/guide/migration.html#using-esbuild-deps-optimization-at-build-time

[aslanalyiev]

Experimental

[aslanalyiev]

implement an option/plugin which supports node core modules/globals

I understand that the goal is browsers....but as a separate option/plugin - it would be cool

[bluwy]

I think this should be implemented in userland instead of something for Vite 4. There are a few options currently like https://github.com/sodatea/vite-plugin-node-stdlib-browser

[aslanalyiev]

I think in 2022 it is a little bit hard to get rid of all packages which are using node global/core modules and if you're working in a big company it is a little bit problematic to include such packages with first line in the description:

Disclaimer: I've only tested this plugin in simple projects. If you encounter any issues, please open an issue with a minimal reproduction in the project repository.

Therefore it would be great to include an official plugin for legacy project/package. Over time everything will move to ESM and the plugin will not be needed, but as an additional option - it would be nice

[mkilpatrick]

I don't think this would be something that couldn't be part of a minor, but would love to see some more SSR love - specifically #9054 and #9446.

Import assertions also remain an issue - #9446

[mkilpatrick]

Potentially expose transformCjsImport so people can manually transform modules the same way Vite does.

[gajus]

Is it possible to use Rollup v3 with Vite v3?

[patak-dev]

Rollup 3 is big enough to require a major on Vite's side. You can already use it with vite@4.0.0-alpha.0, and we'll try to keep Vite 4 scope small so we can release the stable version in a month

[gajus]

Can you update rollup to v3.3.0 in the next alpha release? It includes important changes rollup/rollup#4327

[patak-dev]

We are already on v3.3 (#10890), the next alpha will use it 👍🏼

[gajus]

I saw a conversation on Discord about swc being available in vite v4, but no mention here. Is that happening?

[patak-dev]

Yes, we plan to offer an official React plugin using SWC, and keep the current one using Babel, and document the tradeoffs so users can choose the best one for them.

[i9or]

document the tradeoffs so users can choose the best one for them

Looking forward for this one. Quick question, though. Planning to start a new project with React and TS, should I stick to previous template (with esbuild) or SWC one is production ready?

[bluwy]

You can read more here. Both are "production ready".

[jacekkarczmarczyk]

Would adding SystemJS support be a breaking change? I mean it sounds like just a feature, but maybe it requires changing some internals that would cause backwards incompatibility. If yes, can it be reconsidered as it was rejected by Evan? See #588 (comment) for more details. If it wouldn't be breaking then of course it could be added in some next minor release, so not adding it in 4.0 is not a big problem

Or maybe it is already supported but format: 'system' in rollupOptions.output is not enough? (Also I don't see it being mentioned in docs)

[Rich-Harris]

I'm probably squarely in the minority here, but one change I'd love to see for Vite 4 is getting rid of the config bundling step. It seems harmless, and allows people to use TypeScript to author their configs, but it results in subtle bugs, such as these ones in SvelteKit:

• Ignore Vite timestamp files by default in create-svelte templates (added to .gitignore) sveltejs/kit#7660
• Cannot find base config file "./.svelte-kit/tsconfig.json" sveltejs/kit#7028

Rollup used to do something similar — it would use itself to bundle rollup.config.js files, because it felt weird that you couldn't use ESM inside the config for an ESM-based bundler. Long story short, we (or, let's be honest, I) made a terrible mistake. It caused all sorts of papercuts, and I'm deeply glad it's gone. Using native modules without any unnecessary moving parts is liberating.

Inside a vite.config.js, people's configs would still be typed if they're using defineConfig (as long as the config file is added to the tsconfig's include, and allowJs and checkJs are both true), and if they're not then type safety is a JSDoc comment away:

-import type { UserConfig } from 'vite';

-const config: UserConfig = {
+/** @type {import('vite').UserConfig} */
+const config = {

[mquandalle]

In SvelteKit our build config is currently split in two files : vite.config.js for vite settings, and svelte.config.js for SvelteKit settings. Would enforcing a native JS module for vite config allow merging these two files? or is this an unrelated issue? (asking because as a user I often open the wrong file when I want to edit my build settings).

[benmccann]

That's unrelated. It was done for the best compatibility with the ecosystem of Vite tools and Svelte tools which each look for their own config files

[patak-dev]

We are discussing aligning the output file name format with rollup and esbuild (from [name].[hash].[ext] to [name]-[hash].[ext]). Let us know if you see any problems with pushing this forward in Vite 4:

• feat: align default chunk and asset file names with rollup #10927

[rockwotj]

I see that v4 just hit beta - is there an estimate on when it will be out of beta?

[patak-dev]

We are aiming for this Friday, testing and reports are highly appreciated.

[rockwotj]

I just took a stab at upgrading our project to the beta and ran into a bunch of errors around using styled components (I believe due to the ?inline css changes). There were a ton of warnings around our <file>.styles.ts file imports saying that we needed to change the import to ?inline. It also required a separate install of stylus? I'll try to create a small repro sometime in the next day or two and open an explicit issue.

EDIT: Here's a repro of the stylus issue: https://stackblitz.com/edit/vitejs-vite-1pe6vf?file=App.tsx

[bluwy]

Thanks for testing it @rockwotj. I've made a fix at #11237

[rockwotj]

Thanks @bluwy can confirm that worked and it seems that vite 4 works nicely on my company's codebase now! 🎉

[TheInvoker]

I have a vite 3 project. How can I update it to vite 4? Do I need to make a new project from scratch and copy the files? Or do I simply update the version number in package.json, delete node_modules folder and do npm install?

[benmccann]

Just update the version in package.json and run nom install again

[TheInvoker]

I tried the vite upgrade command, but it doesn't work for me. I get

(!) Could not auto-determine entry point from rollupOptions or html files and there are no explicit optimizeDeps.include patterns. Skipping dependency pre-bundling.

[Employee87]

@benmccann
Vite has a vite upgrade command, but it doesn't work for me. I always get

(!) Could not auto-determine entry point from rollupOptions or html files and there are no explicit optimizeDeps.include patterns. Skipping dependency pre-bundling.

Aren't we supposed to use this or is this old now?