Replies: 40 comments 50 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, not even the TypeScript compiler fully supports path resolutions, and I've found it easier to maintain projects (especially libraries) without it. |
Beta Was this translation helpful? Give feedback.
-
|
RE the vite-tsconfig-paths fork, that issue was fixed in April: |
Beta Was this translation helpful? Give feedback.
-
|
We're discussing removing |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
There's an issue here - JeringTech/Javascript.NodeJS#160 |
Beta Was this translation helpful? Give feedback.
-
|
Related comment down below. |
Beta Was this translation helpful? Give feedback.
-
|
Let's continue discussing removal of SSR CJS format here: |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
How is this related to vite? |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
I think lib mode need to be enhenced:
|
Beta Was this translation helpful? Give feedback.
-
|
or auto-bundling css on a module level would be incredible. Useful for those making component libs |
Beta Was this translation helpful? Give feedback.
-
|
mark. a discssion here： #13617 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Using rollupOptions might make it possible to: rollupOptions: {
preserveEntrySignatures: 'strict',
input: '',
output: {
format: 'es'
},
external: option.external
}, |
Beta Was this translation helpful? Give feedback.
-
|
Better error reporting API! and fully annonated errors can be super nice, can try to put together a proposal for this! |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
very cool and useful idea. Is there an issue for this? @manucorporat |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Related: #9367 which includes a proposal for how to handle linked dependencies. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Is this possible to add before v5? |
Beta Was this translation helpful? Give feedback.
-
|
Just to make it clear, I think we will drop Node 19 as well. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
That sounds good to me 👍 |
Beta Was this translation helpful? Give feedback.
-
|
yeah |
Beta Was this translation helpful? Give feedback.
-
|
Maybe a better way to conditionnaly apply plugins ? export default defineConfig({
plugins: [
!process.env.ENABLE_IMG_MIN === 'true'
? undefined
: ImageMin({
// ...
})
]
}) |
Beta Was this translation helpful? Give feedback.
-
|
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({ ... })
]
}) |
Beta Was this translation helpful? Give feedback.
-
|
This only prevents to keep plugin typing. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
The last time this question was asked, the docs explaining why ESBuild isn't used for production builds was updated to say this:
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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 |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
@iMrDJAi if they are broken shouldn't they be brought up to the current, correct standard instead of bending the tool? |
Beta Was this translation helpful? Give feedback.
-
|
Vite already compiles CJS libraries (like React) to ESM, so I don't think this is an issue. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I would love Vite to have better support for monorepos, as in, running one Vite instances with multiple different configs with full on-demand build and HMR across the projects. #10041 It would also be nice to have a better library build mode that can build a library to multiple files instead of a single bundled file and with externalized assets, for consumption by a bundler in a more efficient manner with tree-shaking and not inlining big assets. |
Beta Was this translation helpful? Give feedback.
-
|
I would you like to add the resolve.fullySpecified like |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
I'd love to see a more fine grained resolution behavior based on the current platform. I created an issue for it here #13780 This will make reusing code across platforms (web, server, ssr, workers and even tests) very smooth. The gist of it is to have Vite resolve |
Beta Was this translation helpful? Give feedback.
-
|
We started discussions to gather feedback about experimental features. We'd like to try to stabilize many of them in Vite 5. If you're using one of these features please share your feedback: CSS
Assets
Optimize Deps
SSR
Misc |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
May we have some customization of which modules vite should install? For example, our team use Vite to build regular non frontend apps so we don't need some frontend-related features. Also @haikyuu mentioned vite-note but it won't be used in most cases when developing the static frontend apps. Instead of downloading a whole bunch of modules and polluting the node_modules, we should be able to pick what we need ourselves or just leave everything as is. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
Could there be made an option to bundle the JS with esbuild instead of rollup for cases where code-splitting is not needed? I recently compared vite's bundling speed to webpack and found it to be 2-3 times slower (see this and linked PR), so it seems it's really rollup that holds back vite's build performance massively and I think esbuild ought to beat webpack. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
We don't plan to have a full esbuild build for the time being. In Vite 4.3, we focused on dev server performance. We should do the same for build time, I think we should have times that are on par with webpack with our current architecture. I see in the linked PR that you saw dependencies as the bottleneck. We have experimental support for using esbuild to optimize dependencies during build (as we already do during dev), so that may be helpful in your case. That being said, an esbuild based build may happen at one point. Rollup is also working on improving performance, so we need to evaluate when the tradeoff of maintaining another build pipeline makes sense. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
Thanks, looking forward to build time optimization. From my testing, the total prod build took around 25s in webpack and 60s in vite. More than 30s of that time is spent bundling The other remaining relatively big dependencies in this case were |
Beta Was this translation helpful? Give feedback.
-
|
Optimising Monaco editor would help many developers with their build times. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
The ability to target browsers (e.g. only browsers in 2023) or add support for browserslist when exporting (CSS, etc). |
Beta Was this translation helpful? Give feedback.
-
|
You can use the legacy plugin for this: https://github.com/vitejs/vite/tree/main/packages/plugin-legacy#targets |
Beta Was this translation helpful? Give feedback.
-
|
@patak-dev One thing that should be improved in the variables that are created at the time of the build, I have come across the scenario that I compile two projects in vite and if I render them on the same page (microfronted), then I come across the scenario that one of the widgets is not rendered since a variable i,x,y,z, etc has already been declared. From my point of view, you should review how to increase the probability that by building an app in vite, those variables that are generated have an almost unique nomenclature to avoid these scenarios. |
Beta Was this translation helpful? Give feedback.
-
|
I join the comment of my friend @t1fmarin , currently my team is facing the same problem. |
Beta Was this translation helpful? Give feedback.
-
|
Could you provide a reproduction? I don't understand why this would be an issue in the first place 🤔 Aren't you using modules? |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
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:
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.
Beta Was this translation helpful? Give feedback.
All reactions