The incorporated tools are actually really amazing:
- vitest, an ultra fast test runner. After using a lot of others, including jest and node's built in one, I love vitest.
- oxlint, replaces eslint but is compatible with its file format and ultra fast, since it isn't written JavaScript. I tried biome, but I found oxlint to have more rules and the eslint compatibility was nice.
- oxfmt, replaces prettier and is faster since it isn't written in JavaScript.
- rolldown, replaces rollup and is compatible with it but it is much faster since it isn't written in JavaScript.
The above are my go-tos in new projects anyhow since they are killer good and fast.
However vitest is still great! Selling points now are stuff like:
- shares config with vite
- works with ESM out of the box (I think Jest still doesn't)
- integrated browser testing mode that is very nice
- overall just has a ton of nicely integrated features
I have my 3000 test project suite completing in 15 seconds on my MacBook Air M3. It is pretty sweet with that setup.
Calling tests has overhead. Also knowing how to schedule and parallelize tests with dependencies is not as "simple".
You already use the first, the second you should be using and has existed for years - it's a jest-compatible runner integrated to Vite.
Rolldown is a part of Vite already (since version 8, alongside other implementing tools like lightnincss).
The ox* suite are native replacements for eslint and prettier. The latter has existed for years. Both of them aim to be drop-in compatible soon.
This is a boring stack.
FWIR, prior to the purchase by Vercel (or was it Cloud flare?), Vite+ was going to be a convenient, no fuss, low movement way set up projects that they sold to businesses for funding.
I think the boring stack would skip the need for most of these. That is 5 different tools to write TypeScript in order to get some HTML, CSS and JavaScript for things that are not covered by modern web standards. Not including the frameworks itself which mostly have the same goal.
AI eliminates a lot of the tedium, grinding tasks, while HTML partials and htmx complement each other perfectly.
Not having to manage frontend framework, SSR states is incredibly liberating. Sprinkle in some vanillla js and redraw specific parts of the page as needed... done
At the time Void Zero was probably looking to monetize the Vite brand but now that they've been acquired by Cloudflare they don't need to do that anymore.
Need another plus? Vite++
Sure beats opening some ancient project and seeing some mix of Gulp, Grunt, webpack and a bunch of other disjointed stuff (I migrated that one over to also use the newer stack).
I believe VoidZero has been acquired by Cloudflare [1], so money should not be an issue. Question is if Cloudflare will be willing to continue letting these people work on Vite and Vite+ features that benefit all cloud platforms, not just Cloudflare.
If you only focus on the front-end and remove Typescript from the equation it becomes easy enough. We'll have to see if Vite+ helps for the more complex cases.
I do have lot of hardforked packages, and dont want to look back. Everything just works.
If you confused by the naming, start from Oxlint https://oxc.rs/docs/guide/usage/linter Rolldown https://rolldown.rs/
Did very little changes to tsconfig during past 6 months adoption
My day-to-day process - get the new package unless it some antd6, echart or some rendering engine or geo spatial lib, clean up with Claude, strict and unify type system and align it with my vite, tsconfig, oxlint tastes. The result - no need to follow libs bloat and supply chain attack issues. Easy to read, easy to fix.
I've worked on both stacks in the last few years across several clients. Honestly like with anything in tech it seems to mostly fall apart with half-regarded usage of the tools in growing teams that don't care about their quality in favour of "get ticket done".
I can't say I would really look forward to bringing this level of needless churn and constant disruption to the rest of my development toolchain. Anyway, Vite+ is really just wrapping existing tools into an abstracted command-line interface? And so I have more layers of indirection to wade through in order to get the thing to do what I want? So far I am not optimistic about this prospect...
I did the migrations and they were not horrible. A few breaking changes but they were relatively isolated. And the speed and improvements over these versions had been quite significant.
Adding stuff for SSR was a major improvement.
Can we please stop the incessant belly-aching over problems that don't exist. I have to question if you even use these tools?
Surely lacking features also creates demand for more tooling.
Feels like an obvious comparison to me, and a very welcome development for the JS ecosystem.
uv made me actually _enjoy_ working in Python again.
manually activating venv, inconsistent python and dep versions, duplicate files taking up space, slow and broken tools, fragmented configs, global state, all of that is gone now. if you never experienced it you have no idea how bad it was.
not all of it was uv specifically (pyproject.toml was a proposal for some time before) but they cleaned it up. its the only reason i even think about python as an option for new projects.
Essentially you pretend to be a library
Still need tsx to do type checking
This is especially hairy when making a typescript library that is distributed non-compiled (without dist/) and is supposed to run in both browser and Node.
`allowImportingTsExtensions: true` (https://www.typescriptlang.org/tsconfig/#allowImportingTsExt..., useful if you're running `tsc` in noEmit mode as a linter)
`rewriteRelativeImportExtensions: true` (https://www.typescriptlang.org/tsconfig/#rewriteRelativeImpo..., useful if you're using `tsc` to compile TS files to JS.
This allows you to use fully-specified imports in TypeScript files, which works basically everywhere — NodeJS, TypeScript, bundlers, etc.
The exceptions are browsers (obviously, only normal JS syntax there), and packages inside `node_modules`, which NodeJS will not do any type stripping for. So if you're writing a library, you'll probably still need to distribute the compiled sources, rather than distributing the raw TypeScript files alone. Or you use the JSDoc syntax for TypeScript, which can do everything that .ts files can do, but is more verbose and idiosyncratic.
This way I could just use node --watch instead of tsx or nodemon.
I'm just wary about anything with a '+' and I assume there is a subscription attached to it.
Looking at this it doesn't look like it.
Looks like they have been acquired by Cloudflare, and pivoted to fully open source, but they haven’t really tweaked their messaging to make that fully land with unsuspecting visitors.
It’s kinda like the reverse situation of open source projects that switch to a source available license, but keep the aesthetics of an open source project. Kinda funny!
How about the dependencies Bun is pulling? How did you ever managed to pass security policies with Bun which has so many segfaults that nobody even bothers to write CVEs for them.
Go gives you a bunch of goodies in the standard library.
Rust provides things like your build system, testing, and package management all together, which is what I assume OP meant.
Vite+ can improve and simplify what developers are already doing with ad-hoc collections of tools. Vite is already an industry standard, and Vite+ has a good chance of achieving that status as well.
You probably need to see a video or gif to get it.
Imse vimse spindel klättra upp för trå'n.
Ner faller regnet, spolar spindeln bort.
Upp stiger solen, torkar bort allt regn.
Imse vimse spindel klättrar upp igen.
I have been doing "modern web" things since essentially day zero (you kids with your fancy JIT compiled javascript interpreters!)
SvelteKit, and by extension, Vite, has been the single most productive webstack I have ever used. If this offers anything on top of that, I welcome it with open arms.
Far from being a meme!
> Vite+ will manage your global Node.js runtime and package manager.
What? Why?
You’re really going all-in if you adopt this; and… for what? A bit of cozy tooling around existing standard ways of doing things?
Ok, sure; I like tools, like vite.
…but even for an opinionated tool, this is extraordinarily opinionated. Like next.js
Im skeptical.
The pitch of bringing things together seems strong, but did we go too far here?
Reading reviews of people using this didn't really convince me.
It seems to be running on the coat tails of the vite name, rather than its own merit.
YMMV
We already do cooldowns and disable preinstall and postinstall scripts on all packages except for ones that actually require it.
I bet if you looked at 70% of your dependencies pulled in, you would be horrified. I would rather have that capabilities via code in my repos at this point.
I don't want to be a vite upgrade engineer.
I'll try to pass on this if I can.