990: Vite Is Taking Over (Vite+)

Wes, Scott, and CJ talk about Vite+, a unified JavaScript toolchain that combines linting, formatting, task running, monorepos, and more. They break down its evolution, open-source shift, performance gains, Node version management, and whether it can realistically replace today’s fragmented dev tooling. Show Notes 00:00 Welcome to Syntax! 00:54 What Vite+ is and what’s changed since launch 03:43 Why the ecosystem needs Vite+ 06:41 What Vite+ actually does for your workflow 10:18 Built-in Node version management 12:32 Type-aware linting with tsgolint and oxc 15:27 Brought to you by Sentry.io 16:28 Should config live inside vite.config? 22:56 Monorepos and task running in Vite+ 26:28 Task caching and faster builds 29:01 Final thoughts and current limitations Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Welcome to Syntax. The JavaScript world was flipped on its head with the announcement of Vite Plus and Void. Now, we're going to be taking two episodes to get into the details on both of these things, what they mean for you, how they fit into your stack, and what they do. In this episode, we are going to be focusing specifically on Vite Plus. What the heck this thing is, what it includes, how you can use it, and where it's at today. As always, my name is Scott Tolinski. I'm a developer from Denver. With me as always is Wes Boss. And this time today, joining us is also CJ.

• 0:40Wes Bos?

  What's up, guys?

• 0:41Scott Tolinski?

  It's a special treat. Hello, hello. CJ, I think this topic requires a lot of conversation. So we thought it'd be great to have CJ in here, get a third opinion on this stuff as we dive deep into what's happening with Vite. Vite Plus. Vite Plus is a unified tool for everything. And this was something that was announced a little bit while back, but now we're here. And guys, how has Vite Plus changed from when it was first announced to today?

• 1:10Wes Bos?

  Yeah, so let's describe what it is really quickly. It's a unified tool chain for JavaScript. And it essentially covers, like, if you have any sort of JavaScript app, whether that's client-side or like full-stack JavaScript, you're probably using V at some point, but you're probably using a whole bunch of other tools as well. And what they're aiming to do is to unify the entire tool chain into like a single, beautiful developer experience. And they had announced this, what, like, I think maybe six months ago? And they said that it was going to be a paid thing? And they've since rolled that back and said, no, V+ is going to be totally open source, totally for the community, which is really cool.

• 1:50Wes Bos?

  Because like, the whole entirety of JavaScript land is, not all of it, but a lot of it is built on Vite, right? And it's really cool that we're going to hopefully get the same developer experience of Vite in the rest of our tool chain.

• 2:06Scott Tolinski?

  Yeah, I've always wondered how the the paid aspect of that was intended to work in the first place. It always felt weird to me when it was announced as like a paid additional. I get that Void Zero needed to make money somehow, but when they first announced it, I was always like, how's that gonna work? So really, really stoked to see that that's gone. Yeah.

• 2:24Wes Bos?

  When they first announced that like V was like making a company, I think I even said on the show, I'm like, they're gonna offer like module task caching, similar to how like Turbo Repo does, right?

• 2:34Speaker 02

  Yeah.

• 2:35Wes Bos?

  And part of this V plus tool is like a monorepo task runner caching, but they also announced their like, their like cloud platform, which is called Void. I don't know that they're gonna offer like cache syncing or anything like that. It seems like they're going more the hosting route. We'll talk about that in the next episode, but it's, yeah, I guess they have to make money at some point in this business, right?

• 2:57Speaker 02

  Yeah, I'll say I wasn't even paying attention until last week when they said it would be open source. Like I, when they initially announced that it would be paid, I, yeah, I do think it would be similar to how, I guess it's Turbo Pak does it. I think also NX has some sort of like module caching layer. So that's probably how they're gonna make their money. The ecosystem needs some sort of consolidation because I think that that's that's one of the biggest pain points here. Like other people have tried to solve it. Like Dino tries to do this with their formater and they have a test runner and they tried to, with the release of Dino V2, they tried to announce themselves as like the unified tool chain. But hearing it come from V, I think is a bit more exciting because you don't have to switch from Node to Dino. Most people are already on V. So yeah, this is good.

• 3:43Scott Tolinski?

  Yeah. And so what kind of benefit, like, why do we need something that's different here? Like, we got our prettier, we got our ES Lent. And I granted, there is an argument there for unifying everything as we've mentioned, but like what other than that?

• 3:57Wes Bos?

  Well, like so much of our tool chain right now is like before we had V, maybe we'll bring it back to that. Before we had V, you spent a lot of time getting your Webpack bundler, your like whatever we were using previously to that. What else were we using? Like Parcel was probably a really good DX as well. You had really like gulp tasks and grunt tasks and all of this stuff. And and V sort of came along and like this stuff just it just mostly just worked. And it was really fast and it was beautiful. And every time there was a major upgrade, you didn't really have to do a whole lot. And it was just like, wow, that's like, that's solved. Like this whole like bundler space of building and dev tools and

• 4:38Wes Bos?

  live reloading and server side running, all of that like pain has mostly been solved. And but there's, there's other tools, right? You have a Linter, Formator, Test Runner, Bundler, Package Installer, Bionic Runner, Mono repos, tasks. You have all of this stuff that sort of comes with it. And you can spend a lot of time on it. Once you get into these really big projects, it just takes a ton of time and it can be really slow. And they're, they're really finicky as well. You know, like, part of the reason people don't want to move out of their editor is because they finally got their like ESLint working when you hit save and it formats, you know, and like, that stuff is so frustrating.

• 5:14Scott Tolinski?

  All my stuff's here. I don't want my stuff moved, right?

• 5:17Wes Bos?

  Yeah.

• 5:17Speaker 02

  Yeah. And I think the way they're trying to solve this is like, the easiest way to think about this is go from six config files to one config file. And we're going to get into it. We're going to show some examples. But you might think, oh, now it's just one file with a bunch of config. The other aspect here is kind of like opinions and sensible defaults, right? Like, a lot of times, when you set up a basic V app with Vtest, you don't need to do too much config. And so if there's just some default config ready to go for you, V plus will handle that. Same thing with linting. Like, I spend so much time setting up my ESLint config, getting it perfect. But if they ship with sensible defaults, you don't even need a Linter config anymore. You can just use all the defaults. Same thing for formatting, task running. Like, I use PNP M for all my projects, because it's really

• 5:58Speaker 02

  good for mono repos and running tasks across multiple packages. But their task runner here is going to be able to solve that. And that's another thing, like, one dev team might be using PNP M, another dev team might be using some like NX. So this unification kind of makes it so that if we're all on the same page, we can probably like innovate faster, move faster, and like all consolidate on the same tools.

• 6:21Scott Tolinski?

  Yeah, and I think it owning everything like version manager even that's something that I really hate having to deal with. I hate having to deal with NVM. I hate having to not have that be tightly integrated. It's like, oh, Nick, you know, I gotta run these commands on my system or whatever. One configuration for all that stuff would be great.

• 6:41Wes Bos?

  So let's go through all of the things that this VIT plus does for you. And a lot of these, they're not just like building their own version of it. They are simply just running it for you. They're sort of putting it all into a single tool chain and then allowing you to have a good developer experience. If you still want to use yarn and whatever weird thing that you have set up in like a weird version of node, it will just do that for you, which is which is really nice for all of your products. So the two big ones that we have here are a linter and a formater. So they have aux lint and aux format, which are rust based linters and formatters. They're prettier and ES lint compatible. And they ship right in there. So basically you go

• 7:25Wes Bos?

  open up your project. And the new thing that they're giving you is this VP, which is VIT plus. So you install this on your machine. What I really like about it is if you type it and you don't know what to type, it just turns into like a little like CLI GUI where you can pick what it is that you want, right? And in my case, I could just say like VP check or VP lint or VP check fix and it will automatically fix them for you. And then it'll go through your entire project and give you your linting errors, your format. It won't give you your formatting errors because it will just fix them for you. And then it will also give you your type errors as well, right? It will integrate with the TypeScript SDK and give you all of those pieces.

• 8:04Scott Tolinski?

  Obviously, it doesn't show itself here in any meaningful capacity because you're not like linting a massive codebase or anything like that. But the speed is really a huge sell for these things. And if you haven't hit speed issues with some of these tools, then you're you probably just haven't been working on big enough projects.

• 8:25Wes Bos?

  You're probably doing, yeah, you're probably not a very good developer. But yeah, like I know people who have like, like Their CI is like 20 minutes of checks, right? And like that sucks when you're trying to like do a quick fix. Because like I think like after like 10 minutes or so, you move on to something else. You forget about it. You gotta poke the right people. You just move a lot slower when these things take that long.

• 8:51Scott Tolinski?

  Can I also say that I really like that they they settled on something very short? VP? I'm the guy that loves that. I love a short command that's easy to remember. Short King loves a short command, that's for sure.

• 9:05Wes Bos?

  Let me tell you one thing I love about this is that like sometimes I have a PNPM project and it's PNPM dev. Sometimes I have NPM package and it's it's NPM run dev.

• 9:16Scott Tolinski?

  Yes.

• 9:16Wes Bos?

  Sometimes it's some weird thing that still uses yarn and I hate that. And I have like a little dev command that will try to suss out if it's PNPM or not. But what this will do is you simply type VP dev. I've been I moved like six or seven projects over to it already because I'm like, I just want to type VP dev. And whatever it's using, it will just start. Yeah, it will figure it out for me and I absolutely love it. There we go. This is the Mad CSS website. It just fired itself up and now it's running on localhost 3000.

• 9:46Speaker 02

  In the ecosystem, Ant Fu actually created a tool called NI that does something similar. Like it figures out, do you need yarn installer, NPM install? But again, it's a ecosystem package and a lot of people don't know about it. I think VIT plus introducing these ideas to the rest of the ecosystem is really great.

• 10:01Wes Bos?

  Yeah. Or like somebody, somebody takes the syntax website and how do you tell them to start it? VP install VP dev. It doesn't matter what tools we're using under the hood. And I know that like node is shipped with something like that where you can use multiple packaging managers. But it never, it never works as well as you think it will.

• 10:19Speaker 02

  And I think maybe that's it's a good time to talk about what Scott mentioned in terms of node version management. Because that's another thing included here that. I thought was really great because you do this on every machine. Like you want to have maybe the LTS of Node running, but you also want to have maybe the latest stuff. Or maybe you have an older project and you need to be running version 18 or 20. When you set up a Vee plus project, it asks you if you want it to manage the Node version and it will pin it to a specific version. Like this is another thing that like there are tools out there for this, but now this is integrated with the project. And so when somebody clones your project down and they use VP, it's going to use the right version of Node.js and no issues with telling them to run a specific version or anything like that.

• 11:02Scott Tolinski?

  I hate Node version issues. I hate it.

• 11:05Wes Bos?

  Yeah.

• 11:05Scott Tolinski?

  It drives me up.

• 11:06Wes Bos?

  Like this is huge for people who have big test suites as well, right? You have a library and you want to run it against seven or eight different versions of Node and you have to like have something that will change it. This is simply just VP, ENV, and then you can switch the versions. And it has like a doctor command. You can see which version you're currently on. I've been using N for the longest time. I know a lot of people use NVM. And then we also found out about FNM during the Data JS survey, which is the new popular one. But this seems to be their own home-cooked version of Node version management.

• 11:41Speaker 02

  It just keeps going back to like the ecosystem already fell in love with Vee. Like we all realize like this is good. They did the right thing. And if they can make the same ideas and choices about other aspects of the ecosystem, like why not trust them? Like, why not kind of consolidate to a single spot?

• 11:56Wes Bos?

  The like worry of me is like we all settle on this one tool. And then like what happens when something better than Oxalent comes out?

• 12:04Speaker 02

  Yeah.

• 12:04Wes Bos?

  But also like I, if there's anybody I trust in this whole ecosystem for building kick-ass dev tools, it's like Vee, right? They've proven themselves to really care about the DX and really care about the perf.

• 12:18Speaker 02

  And it feels like they're setting it up in a way that... Could potentially swap out other tools. They basically give you the entry point, but then, under the hood, other things could be could be being used. So that gives me confidence as well.

• 12:32Scott Tolinski?

  Yeah. Could we talk about the linter being TS Go lint? It uses TS Go lint, which is, one, it's using TypeScript Go, so it's very fast. But it's type-aware linting, and that's via Oxlint. That is an Oxlint package. So according to the readme, it's able to catch syntax-only linting misses, like no-floating promises that would be dropped silently in other linters. So because the linting is type-aware, it can catch bug classes that, like ESlint, could never catch without.

• 13:14Wes Bos?

  Oh, interesting. I can't say I've ever had a problem with that. Have you guys?

• 13:20Speaker 02

  Well, TSlint can do it, but it requires a JavaScript plugin, so it's so much slower. Because there is like type-aware linting in ESlint. I will say, as someone trying to migrate my ESlint configs to Oxlint, this is one of the biggest pain points. If you have some older projects that are pinned to a specific TypeScript version, you can't necessarily jump to TS Go just yet. But if it's a newer project and you can, like, yeah, it's lightning fast.

• 13:45Wes Bos?

  Man, so I moved the MAD CSS website over, and that was using V, TanStack Start, and Biome as the formater. And they have a VP migrate command, which will attempt to take all of your old prettier config, your ESlint config, and move them over. In my case, it didn't move over Biome, because they don't have a Biome migration. But I basically just moved it over to this. And then there was one or two little changes I put in there that were like major. I think the surge started, he did tabs and by default, it's spaces, right? So I just threw on tabs, so the whole project wouldn't get reformatted.

• 14:28Wes Bos?

  But then the rest of it, I was just like, I don't care. You know, I just ran it once, I put in a commit, and it touched on maybe 200 or 300 lines of like different weird formatting. But past that, I was just like, I'm so past the days of caring so much about all of these formatters. Just give me whatever the default is. Probably fine, except for like, I have some qualms around prettier and like, long arrays where it puts a one item per thing. That drives me nuts, but otherwise I'm fine.

• 14:59Speaker 02

  Like, I agree, but if you're on an existing project, I don't want to see a commit with 300 files changed.

• 15:04Wes Bos?

  Yeah, yeah.

• 15:05Speaker 02

  Sometimes it's, it's okay, it doesn't matter, but that kind of messes with the Git history. So that's, that's where I've been struggling is like trying to get a like feature compatible Oxlint that still uses a few ES lint plugins, but then it's slower because it has to use those ES lint plugins. So I think if you can start a project with Oxlint, I think it's great.

• 15:26Wes Bos?

  Yeah, yeah, I agree.

• 15:27Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io/syntax. You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 15:52Scott Tolinski?

  I get your point about the good default stuff though, Wes, because I agree. I think I am like more or less landing on that as well. Because it's like the, the tooling can be such a pain that it's just, just whatever you think is best. And as long as it's the same thing, then I'm fine with it. But there is the one thing that I still really want to have detailed control over that kind of stuff is linting of CSS. I have very strict CSS standards and rules, so I like get really niche into my, my style lint kind of setup. That's something that I would love to see out of this, even though I know this is just a JavaScript tool.

• 16:28Wes Bos?

  One interesting thing about the configs here is that you can put your config in your, your vite config. So if you have Oxlint, Ox format settings, instead of having the external JSON file, you can stick them right in your vite config, which I'm not sure how I feel about that. What do you think? Like, should your config go in your vite config or should you have a separate file? I hate having lots of files in my, in my home directory, but I've kind of just given up on that now that there's 80,000 agents, .md files everywhere.

• 17:01Speaker 02

  I think if you can maybe make a rule, like if your config for that particular tool is no longer than five lines, sure, throw it in there, but the moment it gets bigger, maybe pull it out to a separate file.

• 17:11Wes Bos?

  Yeah, I'm just thinking, like, do other tools need to consume your config other than VIT plus? And I'm trying, I'm trying to think. I don't, I don't think so. I don't, I think like, like in other cases, you were like, yeah, well, like my like, test runner also needs to have my, my config or my CI, but like this tool seems to cover all of those use cases. It also is a, like a pre-commit, so it has Husky built in, meaning that when you make a commit, it will run your lint type and formater for you, which is really nice. So you cannot commit code that does not pass, like whatever. In some cases it adds, I just added a whole bunch of as's or whatever to my code base to make it pass. But I think

• 17:55Wes Bos?

  that's a good thing. Do you, I don't do that a ton on my projects. Do you?

• 17:59Scott Tolinski?

  Wes?

• 18:00Wes Bos?

  Pardon?

• 18:01Scott Tolinski?

  Back that as up?

• 18:02Wes Bos?

  Yes, back my as up.

• 18:07Scott Tolinski?

  Back it up on, yeah. So is this only, this Husky stuff, is this only installed if you're doing their migration scripts?

• 18:15Wes Bos?

  Ah, no, it's, it's by default. So if you just like git commit, like when you, when you do a new project, it will then add it into your, what your, your git folder?

• 18:29Speaker 02

  Can you start a new folder and just do a VP create for us? Let's kind of like walk through what it does? Cause I thought you could choose whether or not you want hooks. I will say that I am a fan of Git hooks, especially on open source projects. I know not everyone is, they like depend on CI, but I, I like to make sure my stuff is good before I push up to CI.

• 18:46Scott Tolinski?

  Yeah. Yeah, they can get annoying sometimes, but I do, I do like them as well.

• 18:51Wes Bos?

  Oh, see VP and NIT, nothing, right?

• 18:53Scott Tolinski?

  Ooh, VP and NIT, interesting.

• 18:55Speaker 02

  At the alias.

• 18:56Wes Bos?

  Come on, you gotta have an alias there. Yeah. All right. So it asks you, do you want a VIT plus monorepo, an app, a library, Tansac start or other?

• 19:06Scott Tolinski?

  Interesting.

• 19:06Wes Bos?

  Which is kind of cool. So the monorepo stuff, we haven't talked about that yet, but like this is a huge use case for it, which is, I want a monorepo with tasks and a complicated setup. So let's just go regular, let's, let's do Tansac start, um, PNPM, yarn or NPM, obviously PNPM. It asks you which agents files you want, which is really cool. And I did find that.

• 19:31Wes Bos?

  Both Claude Code and Cursor did a fantastic job at immediately just switching over to using all VP commands, which is amazing because six months ago could not get the thing to use PNPM for the life of me.

• 19:46Speaker 02

  Yeah, maybe honestly, it's like the VP command is different enough from NPM instead of PNPM that it's like, oh, yeah, I could do this.

• 19:53Wes Bos?

  It adds a VS Code folder, which is just for some VS Code extensions. And then, do you want to set up pre-commit hooks for running formatting, linting and type checking with auto fix it? So this is when you you go ahead and do that. So yes, then it goes ahead and scaffolds out your whole project.

• 20:12Wes Bos?

  What would you like to name it? Tan Wes. What do we want? Deploy to, let's do Netlify.

• 20:22Wes Bos?

  And then this, this is no longer the V plus. This is now.

• 20:24Speaker 02

  Yeah, now we're in Tanstick.

• 20:26Wes Bos?

  Yeah, I'm just gonna keep hitting enter.

• 20:30Wes Bos?

  Now, now we're back, there is already an agents.md file, so we'll merge it. Boom, boom, boom.

• 20:37Scott Tolinski?

  Interesting.

• 20:38Wes Bos?

  Installing. And this is awesome because this is, this is kind of what I've wanted for for super long. I know there's lots of like NPX scaffold out commands, but I, I have like almost burned into my brain, which is NPM init, NPM package set type of module. So it's not ESM. NPM install V, you know, like my like, my terminal almost knows exactly what I want to type every single time. So, all right, here we go. By the way, this is an example of why I will not leave Warp. You see how Warp is suggesting to me what I need to put in here? Everybody who's a Warp hater doesn't know the the beauty of it having context for its suggestions.

• 21:22Wes Bos?

  This is exactly what I want to do.

• 21:24Speaker 02

  I'm not a hater. I've, I've just never gotten past the login screen, but if I did, this.

• 21:27Wes Bos?

  It's not, it doesn't have, I haven't had login screen for like a, like a year.

• 21:31Speaker 02

  I'm out of the loop. Yeah, they lost me.

• 21:34Scott Tolinski?

  I don't want to be a hater no more. Yeah, I like, I like Warp, a big fan.

• 21:38Wes Bos?

  There we go. So like, I just created it and now I can just type like VP check or VP.

• 21:47Wes Bos?

  What do we got here? There we go. Look at all these errors. Formatting issues found. And I can run VP check fix and it will go ahead and fix it. You make a commit, it will run those all.

• 22:01Speaker 02

  Yeah, and I just want to back up what you said about like setting up projects. I find now that I'm using a lot more like agent workflows. Having a good check setup, so like linting, formatting, testing, that the agent can use to validate itself. Like even this weekend, I found myself, every new project I want to do, I got to set all that up again. I made like a starter kit, but VP Plus makes that so simple. Like you have a new project, it has all the checks that agents like to use because they've been trained to just run those checks to make sure they're doing the stuff right. So it is nice for starting a project and then just throwing an agent at it.

• 22:35Wes Bos?

  It's so, so good because anytime you like tell an agent to like make something, I find myself being like, ah, damn it, I forgot to tell it to use this specific tech and it went and used Express or something weird like that.

• 22:47Scott Tolinski?

  Yeah.

• 22:48Wes Bos?

  So it's so nice to like have a non-AI make your scaffold out your choices initially. Monorepos, so this is, this is a huge use case for people using NX or Turbo Repo, something like that. So they created their own task runner. So if you've never used like a Monorepo or Task Runner before, often what will happen is you'll, you'll need to like have a task like build. That in turn needs to run some other scripts that live in your other packages folder, right? You're in your mama package.json, you run something and it needs to like run build in two others or like run a lint on one of them.

• 23:29Wes Bos?

  And by defining what your tasks are, you know, let's take a look at the docs here. Execute run scripts. It obviously can run like package JSON scripts, but I think the more interesting thing is this like task definition, right? If you have a command of VP build, first it depends on running a lint first. Or VP deploy, it first needs to run a deploy script with the, the prod one in there and there's, there should be no cache. For that, but before you do that, you should run build and test, right? Like this is Turbo Repo is is very similar to something like this.

• 24:04Scott Tolinski?

  Yeah, and I like Turbo Repo personally.

• 24:06Wes Bos?

  Hate, hate, hate fussing with monorepos. Turbo Repo made it significantly better, but like I got to a point where I just ripped out a lot of the the stuff from my own code bases because I just I was very confused at many times.

• 24:21Scott Tolinski?

  I actually very recently frustratedly ripped out a monorepo because I was so annoyed with it. And this hopefully, I haven't gotten my hands on this tool specifically yet to to give it a rip. But monorepos, man, feels like hopefully this lands on something that will make this a little bit better. Because they're just no fun to work in.

• 24:44Speaker 02

  Yeah, I've been using P N P M for monorepos, which which is fine. Because it has, yeah, workspaces, it has parallel task runner. I haven't tried to do this, like one task depends on the other with P N P M. I don't know if you can do that, but this sounds really nice because I've had agents that try to run things in the wrong order. And then it's like every new agent has to figure out, oh, I should run lint before I run type check. So having the depends on seems seems really great.

• 25:09Scott Tolinski?

  Yeah, that does seem great. I really just hate installing dependencies in a monorepo. It's like that's such a like.

• 25:14Wes Bos?

  That's that's another thing that they have here, right? Um, here we go. If if you run VP, run whatever, it will run it in the like main package. But if you want to run like, let's say you want to run dev just in like your admin package, right? In this case, you just type there's at my forward slash utilities. Or you can run like filter as well. I had quite a bit of filters with with with P N P M in my package JSON as well.

• 25:40Scott Tolinski?

  I still find that to be obnoxious.

• 25:44Wes Bos?

  For me, I was just like, I ripped out a lot of my Turbo Repo stuff and I just replaced it with just P N P M workspaces and like filter commands and it it worked. Pretty well for for most of my use cases. It's not super complex, though. What else do they have? They have a task runner, monorepo. We talked about that, defining tasks. It's a package installer. It's obviously a bundler and dev tool. That's what Veet is, right? So it will simply just use that. Veet 8 was also announced, which now uses the, I think it uses Roll Down by default, which is their Rust-based implementation of Roll Up.

• 26:21Scott Tolinski?

  Yeah, because lost in all of this, Veet 8 came out, so which uses Roll Down by default.

• 26:27Wes Bos?

  Pretty great. Task caching is is a huge one as well, especially when you have like long CI builds that maybe have like lots of images or CSS sheets that need to be bundled. You can cache the outputs of your like Veet build and then it depends on which host you're in, but many hosts will allow you to cache your node modules. So what a lot of these tools do is they just stick the cache in the node modules folder and then next time you run a build, that will come back. It wouldn't surprise me if they come out with some task caching thing that can be used between teams as well. But this is really cool because it simply just speeds up your deployments, right? If you have, I don't know, like in my course platform,

• 27:12Wes Bos?

  I have probably 25 different like CSS files for different websites and I want them all built out individually. And that doesn't take that long, but sometimes it's not necessary to build those if they haven't been changed, right? So that that cache will will swoop in. And this gets way bigger when you're looking at things like compressing images or doing large JavaScript builds or Wasm things where there's maybe two or three megs worth of something moving around. So that speeds up your builds quite a bit.

• 27:43Scott Tolinski?

  And this is a big reason why Turbo Repo was so fast, right?

• 27:47Wes Bos?

  Yeah, Turbo Repo was awesome for this type of thing. And then I know NX has their own. The other thing that this V+ has is like a like a binary runner. So if you use like NPX, you simply just use VPX as well and that will will run those packages for you.

• 28:04Speaker 02

  On the point of task caching, yeah, they did everything, but like the if you go back to the just the intro thing, this is great even for local dev. I keep going back to agents. I think anybody watching this is gonna be like, what happened to this guy? But the thing like I have agents that are They're running these quality checks after everything. But if they only changed a markdown file, there's no need to rerun the test or rerun the build. And so this task caching basically detects like what files actually changed? What arguments changed? Do I need to rerun test or do I need to rerun lint? Or can I just use the previous output because nothing changed? So like, this would also speed up agent workflows because yeah, it's huge.

• 28:41Wes Bos?

  Yeah, you're right. And especially when you're sitting there waiting for the agent to spit it out. And it's like, now let me just type check the entire project before I go like, you change a markdown file, you know?

• 28:52Speaker 02

  Exactly.

• 28:53Wes Bos?

  Only pre-existing errors. That's my favorite response, you know?

• 28:56Scott Tolinski?

  Yeah. Yeah, only pre-existing errors.

• 29:00Wes Bos?

  Oh, that's cool. So thoughts, what do you, what do you guys think? Are you, are you using this? Are you excited about this? Or is this, is this too overreaching for a tool?

• 29:07Scott Tolinski?

  Thoughts? Yeah. My thoughts is, is that one, I'm going to use this everywhere all the time. It does all the stuff that I wanted to do and it does so in a better way than the current tools I'm using. The biggest bummer's to me is that the framework and plugin support here isn't there to the point where I can just remove all of my tools because the Svelte formatting and the Svelte linting just applies to the JavaScript and the script tags and it's not going to do the HTML. It's not going to check those types of things. So what it cannot do today is it cannot replace my entire tool chain today.

• 29:48Scott Tolinski?

  And that makes me sad because I would love to just rip everything out. And there's some issues about the plugins and what support needs to come before those can be completed. But when I see the announcement, the first thing I think of is can I remove everything today? And sadly, I can't. And the ground that I don't want to be in is supporting Vite plus, plus ES lint and Pretty Air for the things that I need to. And then you have competing things and different formats and all that stuff. I don't want to be in that, that weird mushy middle. I just want it to stink and replace all my stuff. So I will be using this going forward. I'm very excited for it.

• 30:32Scott Tolinski?

  And the only thing I wish I could have with this is a time machine where I could go into the future where I'm not going to have to support all of these things.

• 30:41Wes Bos?

  Yeah. So there, I'm just looking at it, what Ox lint supports.

• 30:47Wes Bos?

  And is that the same support as their their formater as well?

• 30:54Speaker 02

  It didn't look like it from the list.

• 30:55Wes Bos?

  No, Linter, the Linter supports JavaScript and all of its like TypeScript, whatever. JSX and TSX and then like dots felt view and Astro files, but only the script blocks. So we're not, we're not talking like the actual HTML part of it, right?

• 31:12Scott Tolinski?

  Correct.

• 31:13Wes Bos?

  But the formater does support CSS or whatever. But like what you're talking about here is you need, you want linting inside of your svelte templating. And with this, you don't get that. So they essentially need like, they need HTML. This is what biome didn't have for a while, right? They need, they need an HTML parser. And then, once you have an HTML parser, then you can start to branch out and do all of these HTML like languages.

• 31:37Scott Tolinski?

  CJ, what are your thoughts? Final thoughts here?

• 31:41Speaker 02

  Yes, this is great. I think I'm on the exact same thought, like line as you, Scott. Like if I could use all of this in a project with no hiccups in terms of like compatibility, great. But some projects are svelte, some projects don't have full support yet. So I'm excited to see where this goes. But I think like even aux format just was in beta, so it's not stable yet. I think personally, I'm going to have to figure out what my preferred aux lint and aux format setup is. Cause I'm coming from the world of Ant Fu's ES link config, which includes ES lint stylistic. And I have to train myself out of that and use the formater instead. So there's just some, some personal issues I gotta work through, but otherwise like.

• 32:23Wes Bos?

  You got issues.

• 32:24Speaker 02

  I got issues. Otherwise this seems great. I think any new project I spin up, I'm going to give this a go first before trying to build out my whole stack or use some starter template for it.

• 32:34Wes Bos?

  Yeah, I agree. Like for new projects and like small projects that I've moved it to, absolutely awesome so far. But like existing, I haven't moved my like big, big boys over, you know? Course platform syntax site, those types of things that that's going to take a bit more. And not to say that we couldn't use V plus.

• 32:54Scott Tolinski?

  Aspects of it, yeah.

• 32:55Wes Bos?

  Yeah. The rest of it, just not for linting and formatting, right? They can still use the task runner and all the 90% of the other stuff that we talked about. But I'm pretty excited about this. It's due time that this stuff becomes much easier in this ecosystem.

• 33:11Scott Tolinski?

  Tech, so what are your thoughts on this? Drop a comment below. Let us know what you're thinking about both V plus, all aspects of it. Does it go far enough? Does it go too far? Let us know down below.