Vite+ Alpha was released yesterday by VoidZero, and I got pretty hyped for it. I saw a long list of features (seen below) and thought "wow, it's doing so much!". Then I watched the intro video with the ever-pleasant Alexander Lichter and got more hyped, as he sped through a bunch of these features but didn't really dive into any details, so I could only guess how good they'd be...
Then I tried it.... and yeah... it's kinda meh or maybe even bad? Pretty disappointing, I gotta stop falling for hype. Some of the stuff it offers I would even consider it an anti-pattern for most projects?
Here's the list of features they tout (typos are theirs, not mine):
vp env: Manages Node.js globally and per projectvp install: Installs dependencies using the correct package manager automaticallyvp dev: Uses Vite's fast dev experience with native ES modules and instant HMRyvp check: Lints with Oxlint, formats code using Oxfmt and checks types with tsgovp test: Seamlessly integrates and runs Vitest with fast feedback loopsvp build: Generates optimized production builds using Rolldown and Oxcvp run: Executes monorepo tasks with automated caching and dependency resolutionvp pack: Bundles libraries for publishing on npm or creates standalone app binariesvp create: Scaffolds new projects and monorepos with recommended settings
I'm going to go over all these "features", explain why they all suck, and why this is something you can ignore.
vp env - Node version management
This is the most infuriating and disappointing feature of them all. I have spent a lot of time researching and trying out all of the options that exist in this space. I won't go into it here, as I have a full write up (14 pages) with all of my research summarized to help others. I've added vp env to the list with a real evaluation of it compared to all the alternatives.
See: Comparing all Node Version Management tools
To summarize how vp env did:
- It is based around very outdated (2011 era) ideas of Node version management
- Is not spec compliant
- With Node or npm's specifications
- Uses outdated, proprietary format
- Completely manual, does not auto-switch versions
- Bad documentation
- When using it, it is easier to be on the wrong Node version than the correct one
- Has no solution to controlling the npm version for a team
- It's just really bad. They could have literally forked Volta, an existing Rust project that the maintainers stopped supporting only a few months ago, made it spec compliant, and would have had the best-in-class solution. Instead, they aren't even in the top 5 best solutions. Avoid
vp env. Go with proto instead.
vp install
So yeah, why type npm i when you could type vp install and it will run npm i for you?
worthless
The idea here, is if you are using the broken, badly design, vp env then this will use the npm version for your project. But you are better off just using a tool that actually handles your Node/npm version correctly, and running npm i like normal. Go with proto instead.
vp dev
So yeah, why type npx vite when you could type vp dev and it will run npx vite for you?
worthless
You should really just have this in your package.json. Any project that has a package.json should follow the rule that all you need to do is clone the repo and run npm i && npm start and you'll be up and running. If you have to do any other steps, you are almost certainly doing something wrong. Here is a simple example:
{
"scripts": {
"start": "vite dev"
}
}That way if you want to add any other arguments to it, like proxying against a local DB running on a specific port or something, you can easily do that. Example:
{
"scripts": {
"start": "cross-env API_SUFFIX=.apps-local.company.local npm run serve",
"start-local": "cross-env API_SUFFIX=.apps-local.company.local LOCAL_PROXY_PORT=10000 npm run serve",
"serve": "vite --host=0.0.0.0 --port=8080"
}
}If your project doesn't work without me globally installing vp (or literally anything else), you're doing it wrong. Global installs have been considered an anti-pattern in the Node space for over a decade now.
vp check
If you are using Oxlint instead of ESLint, and Oxfmt instead of Prettier, and TypeScript.... then this is a command that runs all of those.
But realistically you probably aren't using that exact tech stack unless you specifically used vp create. Also, you shouldn't be using that tech stack. Let's break down these 3 things:
Linting
If you want the best-in-class tool for linting, with all the best plugins, you're going to use ESLint, hands-down. There have been lots of alternatives to ESLint over the years (especially in recent years), most of them pointing out how much faster they run, but no one cares. We aren't picking ESLint because it's fast, we pick it for all the plugins it has, and these alternatives just can't compete with the massive ESLint ecosystem. Further, you can very easily use your JavaScript knowledge to work with ESLint's ASTs to make your own custom linting rules. It's truly great. These alternatives are all written in something OTHER than JavaScript, and thus writing plugins for them cannot be done in JS.
Oxlint is working on full basic compatibility with all the common rules used in the ESLint ecosystem. This is really great work, and I hope they finish it soon, but it's not done yet, and so I can't really recommend it. These rules are, of course, written in Rust and not JavaScript, so the JS community can't really contribute to features or find bugs. All of these rules are ports from JS community built plugins that are maintained by people passionate about that specific topic the linting rules apply to. For example, they've ported over the rules from the JSDocs ESLint plugin. But now as Rust code. How long can they keep porting over all the changes? I've made a handful of issues on the JSDocs ESLint Plugin's GitHub in the past, and the team there have always implemented a solution super fast, sometimes with a release coming out only hours after making the issue. I think the longest I had to wait was 48 hours once. Those guys are amazing. Big fan. So going over to VoidZero's re-write of their rules means I have to wait not just for the JSDocs guys to add my feature pretty quickly, but also for some VoidZero dev to see that change and write their own version of it. This could be skipped by them just using the JS plugin directly. But that would require Oxlint to have full JS API compatibility with ESLint. Something they are actually working on, but it isn't finished. Who knows how close they'll be able to get. It is currently considered experimental.
Maybe one day they'll have full JS compatibility, and ESLint's ecosystem won't be exclusive to it anymore. But that is a hypothetical future. In the world we live in today, I still would advice against Oxlint, and push people towards ESLint.
Formatting
What can I say about the dogshit technology that is Prettier that everyone else hasn't already said. It's dogshit. It has terrible defaults, most of which you can't change. It's a tool known more for how much it conflicts with other tools than with it's actual stated goal, which is badly formatting code in the worst way possible. It conflicts with EVERYTHING, ESlint, your editor, Vitest, editorConfig, even itself. That's not a joke, Prettier can (and does) conflict with itself (impressive).
The current recommendation is if you see someone using Prettier, you very kindly and as politely as possible, slap them until they stop. All editors have some way of setting up ESLint to run on save, or to run as-you-type to underline lint violations in the code. ESLint can do everything Prettier can do. However, Prettier can only do maybe 0.5% of what ESlint can do. ESLint is a huge powerhouse, so naturally it takes longer to run, especially if you have a lot of complex plugins that do all sorts of things Prettier could never do. This slow speed usually isn't a big deal though, as you can just run eslint --fix as your last commit before pushing up a PR. As long as the linter passes on the CI, who cares when you fixed the code, on every save, or on just the very last commit before merging. Your workflow is whatever works for you.
So now we can finally talk about Oxfmt (pronounced Ahks Fimteh, if it wasn't, why'd they spell it that way). Is it better than Prettier? No... it's literally identical to Prettier. Their goal isn't to finally fix this problem, and give people a good alternative to dogshit Prettier. Their goal is to be EXACTLY IDENTICAL.... but written in Rust. That's it. They are 100% the same garbage tool with the same problems, but a different name. Except written in a language that the users of it can't even read. Awful. Avoid.
Formatters and linters naturally struggle with each other. Oxfmt is no different. You're just better off using ESLint and skipping the formatter step entirely. Let ESLint handle the formatting. It is a dramatically better tool for the job.
TSGO
If you are using the TypeScript Compiler to validate your JSDoc types, or you are in a legacy codebase that is sadly still using the old TypeScript syntax and haven't upgraded to a full JS + JSDocs system yet, then you are probably already using the Go version of tsc. While still being too slow to take serious, it is dramatically faster than the older versions that were laughably slow (or painfully slow depending on your perspective - pick now! Vote on your phone!).
Conclusion
Even if you are using these technologies, I still think you are better off just making custom npm scripts. This allows you to more easily run these commands in isolation, or have variations on them. Example:
{
"scripts" {
"lint:docs": "vite-node --config vite.config.docs.js ./scripts/lintDocs.js",
"lint:js": "eslint --ext .js,.vue lib scripts tests docs vite.config.*.js",
"lint:style": "stylelint \"**/*.css\"",
"lint": "npm run lint:docs && npm run lint:js && npm run lint:style",
"fix": "npm run lint:js -- --fix && npm run lint:style -- --fix"
}
}Linting alone is complex enough in this example before bringing in formatting/type checking. But you get the point. Being able to store your arguments in a reusable npm script is extremely common and useful, and vp check's abilities would be outgrown instantly on most real projects.
vp test
So yeah, why type npm t when you could type vp test and it will run npx vitest for you?
worthless
Creating an npm test script is a standard part of the Node and npm specification. It even forces you to make one when running npm init. You can then run npm t as shorthand for npm run test. I like to have both a test and unit script. This gives you better control over common additional arguments. For example, if your code contains anything related to dates, then to prevent your tests from breaking when ran in a different timezone, you'd want to pass in the TZ environment variable. You may, or may not, want to run in watch mode triggering re-runs automatically on save. And you may or may not want to see coverage reports. Here is an example:
{
"scripts": {
"unit": "cross-env TZ=America/New_York vitest --config vite.config.lib.js",
"test": "npm run unit -- run --coverage"
}
}Setups like this are incredibly common on basically all of the projects I do with testing, so I don't see a world where I'd ever have use for vp test.
I should mention that they provide vp test watch and vp test run --coverage. But again, I'd rather just alias that to the shorter, more customizable options shown above.
Also, unit testing is one of those things that is desperately in need of a revolution in the JS world, and the moment something better than Vitest comes out, I will be switching to it. Today, Vitest is still the best option, but I assume that won't be the case in the long run. I don't see any benefit in locking myself into the VoidZero ecosystem when I could just use anything in the JS landscape instead. JavaScript has the world's largest coding ecosystem, why would I give that up?
vp build
So yeah, why type npx vite build when you could type vp build and it will run npx vite build for you?
worthless
Again, like the others sections, you are better off with customizing your own npm scripts to do builds with whatever arguments make sense. Most of my projects only have the vite build as one part of the build process, with many other steps before or after it. And in the cases where it is the only step in the build process, I don't see any benefit in switching from npm run build to vp build.
Actually, we'll just throw vp run and vp pack in this section too, because I don't feel like repeating myself anymore. These are also aliases for other things that could just be npm scripts. Okay... moving on.
vp create
This is a scaffolding tool. I can see some people finding some utility in this. Just like any other boilerplate or scaffolding tool. This one seems to be focused on Vite projects that use AI tools and might be a monorepo. If that appeals to you to, then whatever, go for it. One thing that bothers me is that it pretends that VS Code is the only editor that exists. Even Oxlint works with a dozen editors. Plenty of tooling out there checks your system for editors and lists them automatically, git's installer for example. I expect once this is out of Alpha, it will be more robust, but we'll see.
In general I'd rather use a boilerplate that is more specific to the type of project I am working on, than just a general-purpose "vite" project.
This is a "meh, fine" tool, but it's also nothing that impressive or to write home about. Boilerplates rarely are. They just exist to speed up the setup process on a new project. Helpful but not that interesting.
Who is this for?
Most of what Vite+ is offering is just an abstraction on top of npm scripts. It wants to be a replacement for Node, npm, NVM, Vite, Vitest, ESLint, Prettier, npm workspaces, and boilerplates. It is in alpha, so the fact that it sucks at basically all of those things, is maybe ignorable by some people? Maybe they'll get better at some point?
Ultimately, it just makes me ask "who is this for?". I don't know. I kinda don't know what audience this is for? I know it definitely is not me.
I could see this being fine for like, the first week or two of a class of students starting off with these technologies. Giving them a streamlined introduction. But for actual, real-world, production apps, you would outgrow the limitations of vp really fast. I'd also be hesitant to introduce people to this abstraction layer, when what it's abstracting.... reallllly isn't that complex. It would feel super unnecessary, and maybe even confusing for beginners to start with and then grow out of. I think I'd be much more interested in a desktop app with a GUI for that audience to start with, and then show them under the hood what it is really doing.
I'm trying to think of it from the perspective of someone new to coding, learning on their own? Maybe this will help ease them in? Maybe it's for people that rarely ever do webdev, and instead focus more on other types of development. So they don't really care what the "best" solution is to any problem, they just want a standardized boilerplate that is "good enough". And I can kinda see this being an overall "good enough" solution, for that audience of devs that just want to "get in, get out, get back to doing what I like" as fast as possible. That does make sense for all the AI stuff it is pushing. People with no interest in actually learning anything about the webdev space can just have an "all-in-one" tool that sets everything up for them, lets the AI write all the code, and then they can go back to doing whatever they do that isn't coding.
As a creator of tools for devs, I personally wouldn't like hearing the tools I make described as "good enough". I would want to strive for the best, and consequently, I want to use the best tools. Vite and Vitest fit that description today. But I'm not in love with either of them, and the moment something better comes around, I will absolutely swap them out. Just like I did with Webpack, Jest, Gulp, Grunt, Sass, jQuery, Backbone, etc. All tools that were, at one time, the best option, but then people made better tools.
But beyond Vite and Vitest, nothing else packaged into vp is "best in class". Maybe one day OxLint will be better than ESLint, but I'm not as hopeful about that as I was yesterday. Oxfmt is just more Prettier trash. And vp env is so bad, I don't see any path forward other than complete abandonment and re-writing it from scratch. The entire premise for it is flawed. I am actively concerned for anyone that tries to use it. The rest of vp is just npm aliases that I would actually call anti-patterns.
So, I ask again, "Who is this for?". I think the truest answer... is the investors behind VoidZero. This is a mostly pointless tool that does little more than try to lock you in to the VoidZero ecosystem, and advertise some of their lesser known (because they're bad) products. Which is something an investor in that company would like to hear, but isn't really of any value to anyone else. There is so little value offered by Vite+ that isn't already available without it. I think this may be doomed to just be a "Vibe coding" tool.
"yuckers" - Wizard People, Dear Reader
In closing
One big problem I have with all of this, is the Rust elephant in the room. Most of VoidZero's projects are just Rust re-writes of whatever the most popular version of that tool already is. They don't really examine the problem being solved and other existing alternatives that have good ideas worth stealing. Instead you just end up with a renamed version of the same thing that is like 40ms faster at the cost of no longer being maintainable by the JS community. What a terrible tradeoff it is indeed. I remember a time, before Node, when the JS community could not create their own tools, and we were stuck waiting for tools to be made for us by people that were willing to. And our tooling was sparse, bad, closed source, and/or internal to specific companies.
Even today, in recent memory, we have been burned by this. The best tool for handling Node/npm versions is Volta. It's amazing, and I love it. However, it is written in Rust, and in the last 6 months, the devs behind it have moved on. It will now be abandoned, because the community using it doesn't write Rust, they write JavaScript. These kind, beautiful, might I even say sexy, Rust developers did us all a great service by creating Volta and showing the world the path forward. But they could not carry the torch forever. We as JavaScript developers must carry our own torches. I look at VoidZero and I just see more Rust code to be abandoned in the future. More tools made for us instead of by us. I will sacrifice those 40ms performance benchmarks, these improvements that are barely, and often not even, humanly noticeable. Sacrifice them for what? For autonomy and sovereignty. For a brighter tomorrow, for my fellow big strong JavaScript developers.
