VoidZero
The JavaScript Tooling Company
398 followers
The JavaScript Tooling Company
398 followers
We are the creators, maintainers, and contributors of some of the most critical infrastructure projects in the JavaScript ecosystem: Vite+, Vite, Vitest, Rolldown, Oxc.
Having Vite, Vitest, Oxlint, and Oxfmt all unified under one CLI is huge. Right now my projects have separate configs for ESLint, Prettier, Vitest, and the build tool – and keeping them in sync is easily 10% of my setup time for any new project.
One thing I'm curious about: how does `vp check` handle framework-specific linting rules? For example, React has its own set of rules (hooks rules, JSX accessibility), and Vue has theirs. Does Oxlint cover those out of the box, or would you still need to layer on additional plugins for framework-specific checks?
VoidZero
@aaron0403 You can add built-in or JavaScript plugins via your vite.config.js (lint key), the same way that Oxlint handles them. The only exception right now is that Oxlint can't support JS plugins with custom parsers, so linting the Vue or Svelte templates doesn't work yet (but the script parts work fine). This is on the roadmap though!
Runtime + package manager + frontend stack in one entry point is a bold scope. Where does Vite+ draw the line - is the goal to replace something like Volta or fnm for runtime management, or is it more of an opinionated layer on top of them?
VoidZero
@spunchev Vite+ is there to fully manage your Node runtime, so you can replace nvm/fmt/Volta with it easily. `vp env` is a standalone implementation.
switched to vite last year and never looked back. curious what the + adds — is it mainly the unified config or are there perf wins too?
VoidZero
@hikaruai_ As the video & website shows, you'll get all you favorite (and fast) tools in one CLI. If you've used them separate before, the biggest benefit in terms of perf is the task runner (vp run) as it can do caching as well and works easily in a monorepo too. In addition to that, package manager & runtime management is the icing on the cake 😋
Unifying runtime + package manager + frontend stack is ambitious. The curl install is clean but how does it handle existing nvm/fnm setups — does it conflict or coexist? That migration path matters a lot for adoption.
VoidZero
@greythegyutae `vp env doctor` will tell you if there are conflicts. If you put `vp` first in your path, it should cause no issues. As Vite+ is reading from package.json (engines/devEngines field) and .node-version, "migration" shouldn't be a problem.
Been using Vite since v4 and it completely changed my dev workflow. Excited to see the unified toolchain approach — does Vite+ handle testing and deployment too, or is it focused on build and dev server?
VoidZero
@alielastal No deployment, but testing (via Vitest under the hood).
Should I use Vite+ if I'm only using Vite? What are its advantages? Thank you.
VoidZero
@mukiwu You should definitely give it a try! The benefit is simple: One CLI for all your favorite (and fast) tools, including linting, formatting, git hooks, testing and vite itself. On top you get a node version + pm manager.