8 ms·
Vite+ Beta
- ivanjermakov 3mo agoCan it be used for Node builds or browser-only same as Vite?
- curtisblaine 3mo agoI'm always curious of the use case when someone proposes Node code bundling. What's the advantage? Obfuscation in SEA?
- ivanjermakov 3mo agoRunning typescript without compilation is still tricky with plain Node. `vite dev` has amazing DX not available for Node programs. I'm wondering if Vite+ tackles this problem.
- curtisblaine 3mo agoDon't we have `tsx` and `nodemon` (or the native Node reloader) for that? What are the DX gaps you see on the server side out of on-the-fly transpilation and reload on watch?
- afavour 3mo agoOne advantage of precompilation is risk reduction. Say tsx gets hacked somehow (hardly unprecedented with Node modules!) you’ve got it running on your production server exposed to the internet. Precompilation on a CI pipeline is still a risk but a significantly lower one.
- pjmlp 3mo agoIf only the whole JavaScript wasn't as dependency hell of single function packages....
- curtisblaine 3mo ago@afavour if you need precompilation in CI can't you simply use... tsc?
- Cthulhu_ 3mo agoIn theory, typescript doesn't need to be transpiled, you can run ts files using `node --experimental-strip-types file.ts` as long as you don't use any code that needs transpilation (like typescript enums). Still need tsx to do type checking
- ivanjermakov 3mo agoNo, because of ESM import resolution rules. Typescript suggests extensionless imports, making it incompartible with ESM and therefore Node. Luckly, `node --import=tsx file.ts` handles imports well. 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. https://github.com/nodejs/node/issues/46006 https://github.com/nodejs/node/issues/46006 https://github.com/microsoft/TypeScript/issues/16577 https://github.com/microsoft/TypeScript/issues/16577
- MrJohz 3mo agoYou can use one of the following: `allowImportingTsExtensions: true` (https://www.typescriptlang.org/tsconfig/#allowImportingTsExtensions 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/#rewriteRelativeImportExtensions 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.
- moogly 3mo agoI transpile for prod, but use --strip-types when running in dev, and all I had to do was to make a 10-line ESM register hook that rewrites .js to .ts if the .js import fails, and then a one-liner import register trampoline script. Not sure I'd do that in prod, but works fine in dev at least. This way I could just use node --watch instead of tsx or nodemon.
- ivanjermakov 3mo agoYes, I use tsx for Node programs. It's not great when sharing the same codebase for both client and server code, they have completely different dev workflows.
- afavour 3mo agoIn my experience the bundling isn’t really the important aspect (though it also doesn’t harm anything), it’s more just having an ecosystem of plugins for code transpiling, static asset inclusion (e.g. text files) etc and a configuration format folks are already used to.
- UnfitFootprint 3mo agoI’ve found if you want interop ts esm and js cjs you need to compile your code - and then `tsc` doesn’t bundle your dependencies for you and outputs incomplete code.
- mnutt 3mo agoIn cases where startup time matters and you have a slow disk, bundling can drastically reduce the number of filesystem calls you have to make for large dependency graphs.
- inbx0 3mo agoFor me, the main benefit is deployment bundle/artifact size reduction. Mostly from dropping unneeded files from node_modules. Many packages include both esm and cjs builds, sources, docs, TS types, etc. stuff that you don’t need in prod. This matters for lambdas, for example, because deployed code size has limits there.
- 1gr14 3mo agoIn my case, for my fullstack framework, I used vite on the server to add my own vite plugin, which can cut client-only code from server code. But it was really needed only when I use my framework with Vite. For example, if we use it with a clean bun setup, then I can do it with bun runtime plugins, which also allow me to modify code on the fly and do it really faster than vite. So I want to say that in server js code we may use vite to modify code during the dev/build process, and I have no idea what else we can use vite for in server/cli code
- tvbusy 3mo agoIt uses Vite so the same limitations as Vite. However, I have been using Vite for my NestJS servers without any problem with `vite-plugin-node`. See example at https://github.com/leosuncin/nest-vite-example/blob/master/vite.config.mts https://github.com/leosuncin/nest-vite-example/blob/master/v...
- deleted 3mo ago[deleted]
- TheAlexLichter 3mo agoI am using Vite+ for CLIs as well, yes. You don't use Vite as dev server then but lint, format, task running and caching is still there!
- bdxn 3mo agoI'd be interested in seeing this implementation if it's publicly available. Do you have a GitHub link? Thanks!
- silverwind 3mo agoI think tsdown is much better suited for CLI and library builds. Vite has many web-isms that don't matter for these.
- UnfitFootprint 3mo agoHere is my particular incantation for targeting node that is working very well: https://pastebin.com/ynz4B5X0 https://pastebin.com/ynz4B5X0 Essentially you pretend to be a library
- overflyer 3mo agoLayer on layer on layer on layer on layer.... Web development is just a meme by now
- papichulo2023 3mo agoPretty much all software is built like that.
- nicce 3mo agoI think web development does not need that many layers. Usually there is a clear purpose for each layer. I think most problems in web are self-created.
- anon7000 3mo agoThis is just what modern languages have out of box. (Like rust and go.) it’s a true shame that web isn’t actually unified behind a type safe language with a single solid toolchain. It’s a huge pain to manage and I’m curious how much money it’s cost the industry. “Vite+” isn’t a true solution to that. There are many competing toolchains. And no default standardized one.
- Quothling 3mo agoI'm not very familiar with Rust, but doesn't cargo pull a lot of external dependencies for most projects? I really like how Go can do everything with just the standard library, but I wasn't aware Rust was similar. For typescript we've moved our stuff to bun. It has it's own risk management perspective compared to node, but at least it's now possible to build web services without having to rely on a bunch of external dependencies. Which in our highly regulated business would require security policies for each dependency explaining the risks, why we accept them and how we mitigate them.
- nicce 3mo ago> without having to rely on a bunch of external dependencies. Which in our highly regulated business would require security policies for each dependency explaining the risks, why we accept them and how we mitigate them. 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.
- colesantiago 3mo agoIs there a subscription with this? 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.
- khurs 3mo agoSays: "It is fully open source under the MIT license"
- deleted 3mo ago[deleted]
- dandaka 3mo agoNaming is worrisome!
- bouk 3mo agoI think that used to be the idea but then they got acqui-hired
- gordonhart 3mo agoMy first thought too. "$name+" is strongly coded now as "subscription service for $name"
- TheCoreh 3mo agoYeah, not only the name: they’re also going with various semiotic signs that are strongly associated with a subscription service, including their website design, choice of typography, and even the press release–style copy. 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!
- incrudible 3mo agoI have removed vite because dev build and reload is noticable slower than just esbuild and browser refresh. Vite does nothing for me that an LLM can not just trivially rebuild in a bespoke manner. YMMV
- curtisblaine 3mo agoHow do you bundle web workers that import dependencies? iirc the issue in esbuild for that is still open and users are manually building their workers as separate entry points, which is very fragile.
- incrudible 3mo agoI build them as separate entry points. And to be clear, esbuild doesn't do everything for me, but the solution is bespoke script, not the whole of something like Vite.
- jml78 3mo agoI am actually pushing our frontend devs to remove more and more dependencies and leverage LLMs to just write the code instead of all the dumbass packages in hellscape of supply chain attacks via node/npm.
- mrbombastic 3mo agoYou are signing up for another hellscape of unmaintainable slop. Enable package cooldowns and only whitelist internal packages and you are better off than 90%
- jml78 3mo agoYou act like the existing packages being published in this ecosystem aren’t already slop or quickly getting there. 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.
- KronisLV 3mo agoI love Vite, Vitest, Oxlint and Oxfmt and look in their direction for most of my new projects! I hope these folks manage to get a bunch of money and can fund the continued development for at least the next decade. 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).
- snorremd 3mo ago> I hope these folks manage to get a bunch of money and can fund the continued development for at least the next decade. 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. 1. https://blog.cloudflare.com/voidzero-joins-cloudflare/ https://blog.cloudflare.com/voidzero-joins-cloudflare/
- GCUMstlyHarmls 3mo ago> Sure beats opening some ancient project and seeing some mix of Vite, Vitest, Oxlint and Oxfmt and a bunch of other disjointed stuff (I migrated that one over to also use the newer stack).
- KronisLV 3mo agoI mean if I see those in N years, I'll be happier than with the older stack that came before them - the jank levels seem to generally be decreasing with every next attempt to get things right!
- dominicrose 3mo agoMaking all this (for example) work nicely together can be tricky: Vite, ESLint, Prettier, Typescript and React, especially if it's full stack with SSR. 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.
- 3mo ago
- paulinho1 3mo ago[flagged]
- ronbenton 3mo agoTruly have so much trouble keeping up with the frontend (or JavaScript?) ecosystem. I so miss working in laravel. Wish more jobs paid well to use it.
- dominicrose 3mo agoTrust me you don't want to work with Laravel Livewire and Alpine.js, that would still require keeping up and for a less than satisfying result.
- TheCapeGreek 3mo agoBecause VILT is dead and Livewire is now on version 1100? 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".
- dgellow 3mo agoyou actually don't have to keep up, whatever you were using still works
- deleted 3mo ago[deleted]
- crumb1e 3mo agoI feel ya, we're slowly phasing out our Laravel monolith for python lambdas. I miss those beautiful Laravel 6 days!
- donaldstuck 3mo agoDoug McIlroy once said: "Make each program do one thing well".
- CharlesW 3mo agoThen he'd love this. Like Unix, Vite+ is a collection of programs that do one thing well.
- noodletheworld 3mo agoI appreciate the effort to bring things together in this but… > 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.
- lioeters 3mo agoSeen this play out again and again: a tool becomes popular, starts incorporating other tools, including mananging language runtime versions. It wants to become the entire platform, to do everything with this one tool. After people get hooked and adapt their workflows to depend on it, inevitably it starts to enshittify. Repeat cycle with new tool.
- nicce 3mo agoThat is one thing that makes me at least afraid of being too dependent of the uv in Python.
- deadbabe 3mo agoIt’s a great move for Cloudflare to have bought up voidzero.
- ewy1 3mo agoit worked for uv so i can imagine a competent team can do the same thing for javascript!
- alexwebb2 3mo agoSurprised to see this is the only uv reference in the comments! 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.
- seanclayton 3mo agoa single tool was the enabler of enjoyment? It seems enjoyment is a fleeting thing these days if that's the case
- tancop 3mo agouv removes all the pain from python packaging. and if you ever used it for anything more than one off scripts you know it used to be a lot of pain. 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.
- sailorganymede 3mo agoI am a big fan of Vite. But I have zero clue what those other tools are. I swear to God, I just put my head down to do some work and all the sudden, frontend tooling has evolved. I wonder if there is a push towards a "boring but works" stack.
- beaker52 3mo agoThis is the latest emerging "boring but works" stack.
- mort96 3mo ago"Latest emerging boring but works" sounds like an oxymoron.
- throw-the-towel 3mo agoOr sarcasm.
- tshaddox 3mo agoSo something can only be "boring but works" if it was created before today?
- mort96 3mo agoYes, it's not boring if it's the new hotness
- montroser 3mo agoVite had five major version in the four years 2022-2026. Version 3 => 4 => 5 => 6 => 7 => 8. Each one of those had breaking changes and required devs to go through a migration. It's too much. And for what? It's not as if it is dramatically better now than it was in version 3. 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...
- jackdh 3mo agoI've followed all the main migrations and I've say they where really quite smooth, can't remember having any major issues and each time it tended to be worth it.
- rglover 3mo agoThe churn is the product.
- enraged_camel 3mo agoThis makes absolutely zero sense. If you're going to post cynically, at least try to have some sort of coherent point?
- rglover 3mo agoTooling instability creates the demand for more tooling.
- c-hendricks 3mo agoThe major change through all of those was solidifying Vite's concepts of "environments" for better SSR support. If you weren't using that, there wasn't much instability. Surely lacking features also creates demand for more tooling.
- dkdbejwi383 3mo agoToolchain Grand Vitesse
- jmull 3mo agoVite pumps out major versions -- that is, breaking changes -- at an incredible rate. I don't want to be a vite upgrade engineer. I'll try to pass on this if I can.
- adeptima 3mo agoExtremely happy user of Vite, Vitest, Rolldown, tsdown, Oxlint, and Oxfmt. 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 https://oxc.rs/docs/guide/usage/linter Rolldown https://rolldown.rs/ 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.
- pier25 3mo agoI think they should find a better name for this project. I find it very confusing since it's not really a better Vite. 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.
- re-thc 3mo ago> I think they should find a better name for this project. Need another plus? Vite++
- kewscombinator 3mo agovite pro max
- scrollaway 3mo agoVite Enterprise Edition Service Pack 3
- ericyd 3mo agoIts vite... plus a bunch of stuff. Plus can mean different things
- ramesh31 3mo agoThat "+" is making me really nervous. Is this just a naming quirk, or the start of them trying to monetize Vite? If the latter, this is a dark day for frontend dev.
- preommr 3mo ago> Is this just a naming quirk, or the start of them trying to monetize Vite? VoidZero got acquired by Cloudflare, which gives out insane amounts of free services, I'd be very surprised if vite is the place they try start pinching pennies.
- johnny22 3mo agoyou missed the monetization phase. It was already attempted before they were acquired by cloudflare. The goal was to sell a tool that integrated all parts of vite and oxc ecosystem (oxlint, oxfmt, vite, vitest, etc) in one place. That stopped right before official cloudflare acquisition announcement.
- jadbox 3mo agoCan I use Astro with this?
- rk06 3mo agoyes, vite+ has full support of vite based tools and astro is built on vite.
- ShineDismal 3mo ago[flagged]