8 ms·
Vite 8.0 Is Out
- slopinthebag 7mo ago> Currently, the Oxc transformer does not support lowering native decorators as we are waiting for the specification to progress Does Oxc also support TS runtime features like constructor parameter properties and enums? I seem to recall in the beta that they had enabled --erasableSyntaxOnly, presumably because Rolldown / Oxc didn't support doing a full transform.
- ameliaquining 7mo agoYes, those work fine: https://playground.oxc.rs/?options=%7B%22run%22%3A%7B%22lint%22%3Afalse%2C%22formatter%22%3Afalse%2C%22transform%22%3Atrue%2C%22isolatedDeclarations%22%3Afalse%2C%22whitespace%22%3Afalse%2C%22mangle%22%3Afalse%2C%22compress%22%3Afalse%2C%22scope%22%3Atrue%2C%22symbol%22%3Atrue%2C%22cfg%22%3Afalse%7D%2C%22parser%22%3A%7B%22extension%22%3A%22ts%22%2C%22allowReturnOutsideFunction%22%3Atrue%2C%22preserveParens%22%3Atrue%2C%22allowV8Intrinsics%22%3Atrue%2C%22semanticErrors%22%3Atrue%7D%2C%22linter%22%3A%7B%7D%2C%22formatter%22%3A%7B%22useTabs%22%3Afalse%2C%22tabWidth%22%3A2%2C%22endOfLine%22%3A%22lf%22%2C%22printWidth%22%3A80%2C%22singleQuote%22%3Afalse%2C%22jsxSingleQuote%22%3Afalse%2C%22quoteProps%22%3A%22as-needed%22%2C%22trailingComma%22%3A%22all%22%2C%22semi%22%3Atrue%2C%22arrowParens%22%3A%22always%22%2C%22bracketSpacing%22%3Atrue%2C%22bracketSameLine%22%3Afalse%2C%22objectWrap%22%3A%22preserve%22%2C%22singleAttributePerLine%22%3Afalse%7D%2C%22transformer%22%3A%7B%22target%22%3A%22es2015%22%2C%22useDefineForClassFields%22%3Atrue%2C%22experimentalDecorators%22%3Atrue%2C%22emitDecoratorMetadata%22%3Atrue%7D%2C%22isolatedDeclarations%22%3A%7B%22stripInternal%22%3Afalse%7D%2C%22codegen%22%3A%7B%22normal%22%3Atrue%2C%22jsdoc%22%3Atrue%2C%22annotation%22%3Atrue%2C%22legal%22%3Atrue%7D%2C%22compress%22%3A%7B%7D%2C%22mangle%22%3A%7B%22topLevel%22%3Atrue%2C%22keepNames%22%3Afalse%7D%2C%22controlFlow%22%3A%7B%22verbose%22%3Afalse%7D%2C%22inject%22%3A%7B%22inject%22%3A%7B%7D%7D%2C%22define%22%3A%7B%22define%22%3A%7B%7D%7D%7D&code=class+A+%7B%0A++constructor%28public+b%3A+number%29+%7B%7D%0A%7D%0A%0Aenum+C+%7B%0A++D%2C%0A++E%2C%0A%7D%0A https://playground.oxc.rs/?options=%7B%22run%22%3A%7B%22lint... For that matter, TypeScript's version of decorators ("experimental decorators") also works: https://playground.oxc.rs/?options=%7B%22run%22%3A%7B%22lint%22%3Afalse%2C%22formatter%22%3Afalse%2C%22transform%22%3Atrue%2C%22isolatedDeclarations%22%3Afalse%2C%22whitespace%22%3Afalse%2C%22mangle%22%3Afalse%2C%22compress%22%3Afalse%2C%22scope%22%3Atrue%2C%22symbol%22%3Atrue%2C%22cfg%22%3Afalse%7D%2C%22parser%22%3A%7B%22extension%22%3A%22ts%22%2C%22allowReturnOutsideFunction%22%3Atrue%2C%22preserveParens%22%3Atrue%2C%22allowV8Intrinsics%22%3Atrue%2C%22semanticErrors%22%3Atrue%7D%2C%22linter%22%3A%7B%7D%2C%22formatter%22%3A%7B%22useTabs%22%3Afalse%2C%22tabWidth%22%3A2%2C%22endOfLine%22%3A%22lf%22%2C%22printWidth%22%3A80%2C%22singleQuote%22%3Afalse%2C%22jsxSingleQuote%22%3Afalse%2C%22quoteProps%22%3A%22as-needed%22%2C%22trailingComma%22%3A%22all%22%2C%22semi%22%3Atrue%2C%22arrowParens%22%3A%22always%22%2C%22bracketSpacing%22%3Atrue%2C%22bracketSameLine%22%3Afalse%2C%22objectWrap%22%3A%22preserve%22%2C%22singleAttributePerLine%22%3Afalse%7D%2C%22transformer%22%3A%7B%22target%22%3A%22es2015%22%2C%22useDefineForClassFields%22%3Atrue%2C%22experimentalDecorators%22%3Atrue%2C%22emitDecoratorMetadata%22%3Atrue%7D%2C%22isolatedDeclarations%22%3A%7B%22stripInternal%22%3Afalse%7D%2C%22codegen%22%3A%7B%22normal%22%3Atrue%2C%22jsdoc%22%3Atrue%2C%22annotation%22%3Atrue%2C%22legal%22%3Atrue%7D%2C%22compress%22%3A%7B%7D%2C%22mangle%22%3A%7B%22topLevel%22%3Atrue%2C%22keepNames%22%3Afalse%7D%2C%22controlFlow%22%3A%7B%22verbose%22%3Afalse%7D%2C%22inject%22%3A%7B%22inject%22%3A%7B%7D%7D%2C%22define%22%3A%7B%22define%22%3A%7B%7D%7D%7D&code=function+sealed%28constructor%3A+Function%29+%7B%0A++Object.seal%28constructor%29%3B%0A++Object.seal%28constructor.prototype%29%3B%0A%7D%0A%0A%40sealed%0Aexport+class+A+%7B%7D%0A https://playground.oxc.rs/?options=%7B%22run%22%3A%7B%22lint... What's not supported is the current draft proposal for standardized ECMAScript decorators; if you uncheck experimentalDecorators, the decorator syntax is simply passed through as-is, even when lowering to ES2015.
- slopinthebag 7mo agoAwesome. Standard decorators support is not a dealbreaker for me, but enums and other types of non-erasable syntax would be. Do you know what the status is on using Rolldown as a crate for rust usage? At the moment most rust projects use SWC but afaik its bundler is depreciated. I usually just call into Deno for builds but would be nice to have it all purely in Rust.
- Benjamin_Dobell 7mo agoTC39 decorators emit just landed in tsgo about 24 hours ago. Hopefully they're available in Vite 8 soon. I'm using them in GodotJS https://github.com/godotjs/GodotJS/commit/a4bafef9f14c103b0972d167c722b0924c221d82 https://github.com/godotjs/GodotJS/commit/a4bafef9f14c103b09...
- krona 7mo agoIt doesn't support const enum, unlike esbuild which supports them well enough to be credible. https://github.com/oxc-project/oxc/issues/6073 https://github.com/oxc-project/oxc/issues/6073
- johnfn 7mo agoVite 8 is pretty incredible. We saw around an 8x improvement (4m -> 30s) in our prod build, and it was nearly a drop-in replacement. Congrats (and thank you!) to the Vite team!
- Griffinsauce 7mo ago4 minutes?! How large is that app? Not meant as a gotcha but I'm surprised because people always tout it as being so much faster than Next. (4m with Turbo would have to be a crazy huge app IME)
- FrostKiwi 7mo agoSame here (10s to 1s). The main reason for this is rolldown [1]. Already had it installed months ago, before it got merged into vite proper. Really awesome stuff. [1] https://rolldown.rs/ https://rolldown.rs/
- bengale 7mo agoWe saw 12m -> 2m on one of our biggest projects. Incredible really.
- christophilus 7mo agoIt blows my mind that there is a 12m build for a JavaScript application. How may lines of code is this app?
- 7mo ago
- brandensilva 7mo agoMan the perf changes for this version are awesome. Thanks Vite.
- deleted 7mo ago[deleted]
- pkilgore 7mo agoCongratulations!
- hackernewsman71 7mo agoholy shit - Vite 8 - rhymes in french! Did they mention that somewhere?
- soulchild77 7mo agoAwesome! Too bad Next.js will never profit from these incredible community efforts, because Vercel suffers from NIH.
- pjmlp 7mo agoThey have the enterprise partners that make Next.js the only officially supported SDK on their SaaS integrations. See Sitecore Cloud, Sanity, Contentful,....
- rk06 7mo agoReally the enterprise partner supports next, but not vanilla js sounds stupid? Honestly I expect them to prioritize nextjs and react given the popularity, but still be open to vanilla js. I checked sitecore cloud to have special integration for nextjs and reactjs. But it also support vanilla js as well. Are there really anyone who is exclusive to nextjs?
- pjmlp 7mo agoVanilla JS is "supported" if you write the missing parts, e.g. layout service, visual editing integration,... In many places they will say it is supported, but when you look into the details only React/Next.js work out of the box without additional work. A bit like you can deploy Next.js on Vercel, or do it yourself somewhere else.
- rvcdbn 7mo agomaybe of interest: https://github.com/cloudflare/vinext https://github.com/cloudflare/vinext (haven't tried it myself)
- vijaybritto 7mo agoIt's not a good piece of software. Breaks in many places
- 7mo ago
- verma_yatharth 7mo agoI tried it and I saw more than 6x improvement in speed. It's on the top. Awesome tool 1
- pjmlp 7mo agoAnother rewrite in Rust. What about finally stop using node.js for server side development?
- vijaybritto 7mo agoThis is for tooling. Node.js has been extraordinarily useful for building build tools. We're outgrowing it's capacity and rightfully moving to a compiled language. Also faster tooling is essential for establishing a high quality feedback loop for AI agents
- pjmlp 7mo agoWhy go halfway, embrace compiled languages in the backend. Fast all the way down, especially when coupled with REPL tooling.
- omnimus 7mo agoBecause writing Rust backend is needlessly complex for majority of projects.
- potwinkle 7mo agoI've had a great time using Rust with Actix as the framework.
- pjmlp 7mo agoStill easier than dealing with node dependencies, webpack and co, they make me wish to write ASP with OCX components instead.
- drawfloat 7mo agoYour complaint is with Vite – famously incredibly simple and reliable to work with – using Rust, but you're bringing up webpack's complexity? Node dependencies are fine, add an npmrc file to have it default to exact versioning and you solve 90% of common day to day problems. It's not ideal, but nor is cargo's mystery meat approach to importing optional features from packages.
- nebezb 7mo ago> Built-in tsconfig paths support A great QoL change. One less place to duplicate (and potentially mistake) a config.
- c-hendricks 7mo agoThis is great news, but people should also try using regular nodejs import aliases and see if they're viable for their project.
- Timon3 7mo agoI keep trying the "native" solutions every so often, but every time I quickly hit some snag that makes me question why I'm not just using the solution that actually works. As an example, I just generated a new project using create-vite & added two subpath imports: { // ... "imports": { "#assets/*": "./src/assets/*", "#/*": "./src/*" }, // ... } The second one (#/*) is similar enough to what I usually use (@/*), and it's supported in Node since v25.4.0! Yet when I try to import the file at projectRoot/src/router/index.ts using: import router from "#/router/index" VS Code shows an error: "Cannot find module '#/router/index' or its corresponding type declarations." Now, imports from e.g. "#assets/main.css" work, so I could work around this issue - but this is what I keep experiencing: the native variant usually kinda works except for the most common use case, which is made unnecessarily awkward. For a long time this is what ESM used to feel like, and IMO it still does in places (e.g. directory imports not working is a shame).
- arkon_hn 7mo agoYou need Typescript 6 for that too: https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-rc/#subpath-imports-starting-with-#/ https://devblogs.microsoft.com/typescript/announcing-typescr...
- c-hendricks 7mo agoI'm confused myself. I have one project that uses package json aliased imports and TS doesn't complain. Then another where it does.
- ptak_dev 7mo ago[dead]
- karel-3d 7mo agoYesterday I stopped hating AI because it converted an old webpack project with impenetrable plugin settings to a single simple Vite config. I still don't understand how people used to think scripts like this are the proper way to bundle an app. https://github.com/facebook/create-react-app/blob/main/packages/react-scripts/config/webpack.config.js https://github.com/facebook/create-react-app/blob/main/packa... vite is great, is all I am saying
- jjice 7mo ago800 lines config to compile code that's later interpreted is wild. I get the general idea behind having a script instead of a static config, so you can do some runtime config (whether or not we should have runtime changes to config is a different conversation), but this is absurd. I'm a big believer in fully reviewing all LLM generated code, but if I had to generate and review a webpack config like this, my eyes would gloss over...
- karel-3d 7mo agoNo no no, the script on the link was BEFORE llms. That was how it used to be done before. That was the recommended facebook way. The LLM generated vite config is 20 lines
- jjice 7mo agoOh yeah, I got that - my comment is a bit confusing reading it back. The fact we used to built trash like that blows my mind. Makes me content having been on the backend.
- ricardobeat 7mo agoPeople fought to replace the tools of the era with this. It had some advantages over time - ES6, a good plugin ecosystem, react adoption - but quickly it just became "the standard" which everyone is afraid to question. I used to maintain a build workflow library [1] a lifetime ago; while our frontend build needs have evolved way beyond it, I can't avoid the feeling that we overengineered a little too much. [1] https://github.com/ricardobeat/cake-flour https://github.com/ricardobeat/cake-flour
- homebrewer 7mo agoVery pleased to see such performance improvements in the era of Electron shit and general contempt for users' computers. One of the projects I'm working on has been going for many years (since before React hooks were introduced), and I remember building it back in the day with tooling that was considered standard at the time (vanilla react-scripts, assembled around Webpack). It look maybe two minutes on a decent developer desktop, and old slow CI servers were even worse. Now Vite 8 builds it in about a second on comparable hardware. Another demonstration of how much resources we're collectively wasting.
- vbezhenar 7mo agoIt is especially weird because JavaScript was not supposed to be processed at all! This is all wrong if you ask me. Web development should strive to launch unchanged sources in the browser. TypeScript also was specifically designed so engine could strip types and execute result code. These build tools should not exist in the first place.
- imfing 7mo agoAwesome! been using Vite since its early days. really excited to see how it's improving the JavaScript and TypeScript tooling landscape and how it continues to evolve
- gdorsi 7mo agoSweet, great job Vite team! I wonder how much of the Rollup bundling magic has been ported to Rolldown. One thing that always made this kind of switch to Rust has always been that Rollup has become so sophisticated that's hard to replace with something new.
- shunia_huang 7mo agoAh, wondering how long it will take Angular to replace it's sh*t building tool chain to fully vite compatible, hope it could happen before I change may career path or retire.
- Klaster_1 7mo agoThey recently put out a new roadmap item to adapt the compiler to modern tools: https://angular.dev/roadmap#developer-velocity https://angular.dev/roadmap#developer-velocity . Given the great track record of recent Angular road map deliverables, I think they'll come up with something at least faster than what we have now. Angular already runs on Vite, and the fact that Vite 8 exposes AST level plugin endpoints are good signs. Not waiting 1 minute for unit test suite or `ng serve` cold start would be very welcome indeed.
- JulianPembroke 7mo ago[flagged]
- moretti 7mo agoThanks to the Vite team for building a faster, modern bundling solution on a fully open source stack that isn't tied to a specific framework...cough cough, Turbopack
- throwaway290 7mo agoOutsider question: why use Rollup when Esbuild exist? Is esbuild not enough for production builds?
- rk06 7mo agoit is not. lack of plugin support is sufficient to block adoptions among other things.
- throwaway290 7mo agobut it has plugin support? what kind of plugins you mean?
- rk06 7mo agolook at plugin api limiation here: https://esbuild.github.io/plugins/#svelte-plugin https://esbuild.github.io/plugins/#svelte-plugin esbuild's plugin support is limited which is why vite had to use rollup for prod build.
- abrztam 7mo agoalso since typescript is being ported to go and rolldown is rust, they're stuck using IPC, so they miss out on native stuff like type awareness that a pure go toolchain would get for free
- h4ch1 7mo agoI've been using rolldown-vite for the past 3-4 months with absolutely no issues on a very large monorepo with SvelteKit, multiple TS services and custom packages. Just upgraded to 8 with some version bumping. Dev server time reduced to 1.5s from 8s and build reduced to 35s from 2m30. Really really impressed.
- raydenvm 7mo agoYeah, it makes you wonder how much computing power the industry has wasted over the years on tools that nobody questioned because "that's just how long builds take." We planned our work around it, joked about creating breaks, and built entire caching layers to work around it. Kudos to the Vite maintainers!
- jillesvangurp 7mo agoBuild performance has been a pet topic for me for quite some time when I realized I was wasting so much times waiting for stuff to build 14 years ago. The problem is especially endemic in the Java world. But also in the backend world in general. I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decade ago). That took something like 10 minutes. With Kotlin/Spring Boot, compilation is annoyingly slow. That's what you get with modern languages and rich syntax. Apparently the Rust compiler isn't a speed daemon either. But tests are something that's under your control. Unit tests should be done in seconds/milliseconds. Integration tests are where you can make huge gains if you are a bit smart. Most integration tests are not thread safe and make assumptions about running against an empty database. Which if you think about it, is exactly how no user except your first user will ever use your system. The fix for this is 1) allow no cleanup between tests 2) randomize data so there are no test collisions between tests and 3) use multiple threads/processes to run your tests to 1 database that is provisioned before the tests and deleted after all tests. I have a fast mac book pro that runs our hundreds of spring integration tests (proper end to end API tests with redis, db, elasticsearch and no fakes/stubs) in under 40 seconds. It kind of doubles as a robustness and performance test. It's fast enough that I have codex just trigger that on principle after every change it makes. There's a bit more to it of course (e.g. polling rather than sleeping for assertions, using timeouts on things that are eventually happening, etc.). But once you have set this up once, you'll never want to deal with sequentially running integration tests again. Having to run those over and over again just sucks the joy out of life. And with agentic coding tools having fast feedback loops is more critical than ever.
- Sammi 7mo ago
- punkbit 7mo agoMigrating straight away! Thank you!
- Aldipower 7mo agoAs I am interested in long time maintainability (should still work in 10 years) with my projects I am just using esbuild directly. I am not interested in adjusting my projects, just because things changed under the hood in "wrappers" like Vite and I suddenly have a lot of work.
- emadda 7mo agoesbuild has been very stable for my projects too. I think it is the only tool in the JS ecosystem that has not broken after a few years.
- christophilus 7mo agoThis is the way. Trivial to get live reloading working. HMR is overrated. I went with esbuild in my last project, and have no regrets. Also, used my own 100-line end-to-end typed RPC layer with Zod validation doing the heavy lifting. No codegen required for any part of the project other than generating types from Postgres. No regrets there, either. The only thing I would have changed in that project is I would have used Kysely instead of just raw porsager.
- silverwind 7mo agoIIRC, esbuild is still lacking code splitting.
- chearon 7mo agoesbuild still doesn’t support top-level await. And live reloading is way, way slower than HMR.
- brillout 7mo agoVite+, Void Cloud, Void Framework... an epic battle between Vercel and Void is coming. The PRC (aka server functions) demo [0] is particularly interesting — end-to-end type safety (from DB to UI) is a major milestone for JavaScript. We've been doing a lot of RPC design work in that space with Telefunc (tRPC alternative) [1] — it's a really hard topic, and we're looking forward to collaborating with the Void team. (Also looking forward to contributing as the creators of Vike [2].) [0]: https://www.youtube.com/watch?v=BX0Xv73kXNk https://www.youtube.com/watch?v=BX0Xv73kXNk (around the end of the first talk) [1]: https://telefunc.com https://telefunc.com (see the last PR) [2]: https://vike.dev https://vike.dev
- yurishimo 7mo agoYou say that, but isn't Vercel also a Void(0) investor in a roundabout way? The big news regarding Void Cloud is that it all seems to be built on Cloudflare workers. The landing page is very light on info atm too. [0] I am super excited that they are MIT open sourcing Vite+ however. In that realm, they are obviously targeting Bun as their main competition. Unfortunately for Bun, if they are forced to help Anthropic more than they can focus on OSS, they might lose their current (perceived?) advantage. 0: https://void.cloud/ https://void.cloud/
- brillout 7mo agoDoesn't seem like it — see VoidZero investors [0]. > Unfortunately for Bun, if they are forced to help Anthropic more than they can focus on OSS Curious: is that speculation, or based on observation? [0]: https://voidzero.dev/about https://voidzero.dev/about
- yurishimo 7mo agoIm pretty sure Accel is also heavily invested Vercel. Regarding the Bun comment, that is speculation on my part. I have no real horse in the race but Anthropic didn’t buy them for lols.
- 7mo ago
- chrisweekly 7mo agoAwesome news. Amid all the (real and perceived) js ecosystem churn, vite has been consistently excellent for dx and production. The unified rolldown bundler is only going to increase vite's appeal and widen the gap as the fastest, most pragmatic and flexible foundation for ts/js projects. Huge fan, speaking from deep experience (webdev since 1998).
- deleted 7mo ago[deleted]
- vite_throwaway 7mo agoI have a small React project using vite 7 and have the following in my config so that vite interprets ".js" files as JSX: // See https://github.com/vitejs/vite/discussions/14652 esbuild: { loader: "jsx", include: /.*\.jsx?$/, exclude: [], }, optimizeDeps: { esbuildOptions: { loader: { ".js": "jsx", }, }, }, Note the comment at the top. I had no idea how to come up with this config by checking the documentation pages of vite and its various related tools. Luckily I found the GitHub issue and someone else had come up with the right incantation. Now this new vite uses new tools, and their documentation is still lacking. I spent half an hour trying to figure out how vite (and related tools that I had to navigate and try to piece a coherent view of: esbuild, oxc, rolldown, etc.) might be convinced, but gave up and stayed with vite 7. Someone could respond with a working solution and it would help, sure, but these tools sure as hell have documentation issues.
- spiros 7mo agoThe solution here is working for me: https://github.com/vitejs/vite/discussions/21505 https://github.com/vitejs/vite/discussions/21505 Though sometimes oxc complains about JSX in JS when running vite, but it still works fine.
- vite_throwaway 7mo agoThanks, I will consider this workaround later on. Another instance is the use of rollupOptions.output.manualChunks that now has to be rewritten, maybe that would be less frustrating to fathom.
- iainmerrick 7mo agoSorry if this comes across as overly facetious — I’m sure you have a reason for doing it that way! — but would it not be easier just to bow to convention and rename your .js files to .jsx?
- vite_throwaway 7mo agoProbably. It's just that I've always used .js for my projects (decades). Such a rename would likely result in configuration changes to the other tools I use, but indeed they are better documented. When faced with a multiplicity of conventions I pick one and stick to it; the tools are flexible enough to work with it I'm sure, the real issue is of discoverability.
- useftmly 7mo ago[flagged]
- lioeters 7mo agoThat's the boat I'm in with several static sites, from tens to hundreds of pages, build on Next.js and stuck a few major versions behind because I didn't have the motivation to upgrade them. One of these days I'll roll up my sleeves and convert them to Vite, and finally be free of that awful framework.
- useftmly 7mo ago[flagged]
- deleted 7mo ago[deleted]
- upsuper 7mo agoI contributed this change in Vite 8: > Wasm SSR support: .wasm?init imports now work in SSR environments, expanding Vite's WebAssembly feature to server-side rendering. While the process was relatively slow, I really appreciate the extra effort that the team have put on even this minor feature add. They not only guided me towards more compatible and idiomatic approach, but also added docs and helped keeping the code up to date before merging.
- bovermyer 7mo agoThis is a fun insight, thank you for sharing that! I like Vite as a tool, but knowing that the Vite folks actually care about helping others learn and contribute is awesome.
- raphaelmolly8 7mo ago[dead]
- repulsio 7mo agoVite 8 has been a huge disappointment: https://github.com/vitejs/vite/issues/21939 https://github.com/vitejs/vite/issues/21939 Build filesizes have doubled... No build speed gain is worth that... I would take a slightly longer build time for half the filesize any day