Welcome to Syntax.

The JavaScript world was flipped on its head with the announcement of Vite plus and void. Now we're gonna 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 Bos. And this time today, joining us is a special treat. CJ. It's a special treat. Hello, Pnpm.

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 Wes 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? Yeah. So let's describe what it is really quickly. It's a unified

tool chain for JavaScript, and it essentially Vercel, like, if you have any sort of JavaScript app, whether it's client side or, like, full stack JavaScript, You're probably using Vee at at some point, but you're probably using a whole bunch of other tools as well. And 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 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 and said, no. V plus is going to be totally open source, totally for the community, which is really cool because, like, the whole entirety of JavaScript land is is not not all of it, but a lot of it is built on on Vite. Right? And, it's really cool that we're going to hopefully get the same DevOps experience of Vite in the rest of our our tool chain. 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 addition. I I get that void zero needed to make money somehow. But when they first announced that, I was always like, how's that gonna work?

So really, really stoked to see that that's gone. Yeah. When they first announced that, like, Vee Wes, like, making a company, I think I even said it on the show. I'm like, they're gonna offer, like, module task caching similar to how, like, Turpor Deno does. Right? Yeah. And part of this v plus tool JS, like, a monorepo task runner caching, but they also announced their, like, their, like, cloud platform, which is called VoIP. 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 Node. But it's yeah. I guess they have to make money at at some point in this business. Right? Yeah. I'll I'll say I wasn't even paying attention until

last week when they said it would be open source. Like, I I when they initially announced that it would be paid, I yeah. I I I do think it would be similar to, how, I guess, its TurboPack does it. I think also NX has some sort of, like, module caching layer. So that's probably how 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, Deno tries to do this with their formatter, and they have a test runner, and they tried to it with the the release of Deno v two, they tried to announce themselves as, like, the unified tool chain.

But Mhmm. Hearing it come from Vite, I think, is a bit more exciting because you don't have to switch from Node to Deno. Most people are already on Vite.

So, yeah, this is good.

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

Well, like like, so much of our tool chain right now is like like, before we had Vite maybe we'll bring it back to that. Before we had Vite, you spent a lot of time getting your webpack bundler or your, like, whatever we were using previously to that. What else were we using? Like, Parcel was probably really good DX as well. You had really, like, Gulp tasks and Grunt tasks and all of this stuff. And and Veek 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, bundlers space of building and dev tools and live reloading and and Vercel side running, all of that, like, pain has has mostly been solved. And but there's there's other tools. Right? You have a linter, formatter, test runner, bundler, package installer, binary runner, monorepos, task. You have all of this stuff that sort of comes with it, and and you can spend a lot of time on it. Once you get into these really big projects, it just just takes a ton of time, and and 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 wanna 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, it that stuff is so frustrating.

All my stuff's here. I don't want my stuff moved. Right? Yeah. 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 I we're gonna get into it. We're gonna 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 Wes you set up a basic VIT app with v test, you don't need to do too much config. And so if there's just some default config ready to go for you, Vite 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 PNPM for all my projects because it's really good for Node repos and running tasks across multiple packages. But their task runner here is gonna be able to to solve that, and that's another thing, like, one dev team might be using PNPM, another dev team might be using Oh, yeah. 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.

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, okay. Now I gotta run these commands on my system or whatever.

One one configuration for all that stuff would be great.

So let's go through all of the the things that this Vite 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 a good developer experience. If you still wanna 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 our products. So the two big ones that we have here are a linter and a formatter. So they have, aux lint and aux format, which are rust based linters and formatters. They're prettier and ESLint compatible, and they ship right in there. So, basically, you're gonna open up your project, and the new thing that they're giving you is this VP, which is v 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 in my case, I could just say, like, VP check or VP ESLint 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 it will integrate with type the TypeScript SDK and give you all of those pieces.

Obviously, it doesn't show itself here in any meaningful capacity because you're not, like, linting, a massive code base 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're

you probably just haven't been working on big enough projects because doing yeah. You're probably not very good developer. But, yeah, like, I know people who have like like, their their CI is, like, twenty minutes of Yeah. Of checks. Right? And, like, that sucks when you're trying to, like, do a quick fix because, like, I I think, like, after, like, ten minutes or so, you 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.

Can I also say that I really like that they they settled on something very Scott, VP? I'm the guy that loves that. I love a a short command that's easy to remember. Short king loves a short command. That's for sure. 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 an NPM package, and it's it's NPM run dev. Yes. 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 you just simply type v p dev. I've been I moved, like, six or seven projects over to it already because I'm like, I just wanna 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 local host 3,000.

In the ecosystem, Antfue actually created a tool called NI that do does something similar. Like, it figures out, do you need Yarn install or npm install?

But, again, it's a ecosystem package, and a lot of people don't know about it. I think v ESLint introducing these ideas to the rest of the ecosystem is really great. Yeah. Or, like, somebody somebody takes the syntax website, and how do you tell them to start it? V p install, v p 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 warp you can use multiple package managers, but it never it never works as well as you think it will. And, I think maybe that's a 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 I I do this on every machine. Like, you wanna have maybe the LTS of Node running, but you also wanna have, maybe the 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 v a Vite plus project, it asks you if it if it 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 there are tools out there for this, but now this is integrate with integrated with the project. And so when somebody clones your project down and they use VP, it's gonna use the right version of Node. Js and no issues with telling them to run a specific version or anything like that. I hate Node version issues. I hate it. Yeah.

And Drives me nuts. Huge for people who who have big test suites as well. Right? You you have a library, and you wanna 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 VPEnV, and then you can switch the Vercel, and it 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 Npm, and then we also found out about f n m during the Stata JS survey, which is the new popular one. But this seems to be their own home cooked version of node node version management. It just keeps going back to, like, the ecosystem already fell in love with Vite. 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 a single spot? The, like, worry of me is, like, we all settle on this one tool, and then, like, what happens when something better than ESLint comes out? Yeah. But, also, like, I if there's anybody I trust, in this whole ecosystem for building kick ass dev tools, it's it's like Vite. Right? They've they've proven themselves to to really care about the DX and really care about the perf. And it feels like they're they're setting it up in a way that

could potentially swap out other tools. They they basically give you the the entry point, but then under the hood, other things could be could be being used. So Yeah. Gives me confidence as well. Yeah. Sanity talk about the linter being,

t s Golint? It uses t s Golint, which is, is one. It's using TypeScript Go, so it's very fast.

But it's type aware linting, and that's via ESLint. That is an Oxland package.

So according to the Read Me, that it it's able to catch syntax only linting misses, like Node 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.

Oh, interesting.

I can't say I've ever had a had a problem with that. Have you guys? Well, TSLint can do it, but it requires a JavaScript plug in, so it's so much slower. Because there is there are there is, like, type aware linting in ESLint.

I won't say JS someone trying to, migrate my ESLint configs to Oxlint, this this is one of the biggest pain points. If you have some older projects that are, like, pinned to a specific TypeScript version, you can't necessarily jump to T s Go just yet. But if it's a newer project and you can, like, yeah, it's it's lightning fast.

Man, so I moved the mad CSS website over, and that was using Vite, 10 stack start, and Biome, as the formatter. And and they have a Npm migrate command, which will attempt to take all of your old, like, Prettier config, your ESLint config, and move them over.

In my case, it didn't move over Biome because they don't have a 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 it. He he he did tabs and by default, it's spaces. Right? So I just threw on tabs so the whole project wouldn't get reformatted.

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 it touched on, I don't know, maybe two or 300 lines of, like, different weird formatting. Yeah. 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 JS.

It's probably fine. Except for, like, I have some qualms around prettier and, like, long arrays where it puts up one item per

thing. That drives me nuts. But, otherwise, I'm fine. Like, I agree. But if you're on an existing project, I don't wanna see a commit with 300 files changed. Yeah. Yeah. Yeah. Sometimes it's it it's okay. It doesn't matter. But that kinda messes with the Git history.

So Yeah. That that's that's where I've been struggling is, like, trying to get a, like, feature compatible ESLint that still uses a few ESLint plugins, but then it's slower because it has to use those ESLint plugins. So I think if you can start a project with ESLint, I think it's great. Yeah. Yeah. I agree.

And if you want to see all of the errors in your application, you'll want to check out Sentry at century.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 century.io/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

I get your point about the, good default stuff, though, Wes, because I I agree. I I think I 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 I, like, get really niche into my my style and kinda setup. That's something that I would love to see out of this even though I know this is just a JavaScript,

tool. One interesting thing about the the configs here is that you can put your config in your your VIT config. So if you have auxilint aux 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 kinda just given up on that now that there's 80,000 agents, MD files everywhere.

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 Mhmm. It gets bigger, maybe pull it out to a separate file. Yeah. I'm just thinking, like, do other tools need to consume

your config other than Vite plus? And I'm try I'm trying to think. I don't I don't think so. I don't I think, like like, in other cases, you'd be 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 built in, meaning that when you make a commit, it will run your ESLint type and formatter for you, which is really Node. So then you cannot commit code that does not pass, like, whatever.

In some cases, it adds I just added a whole bunch of ases or, whatever to my code Bos to make it pass.

But Yeah. I think that's a good thing. Do you I I don't do that a ton on my projects. Do you? Plus, you back that ass up? Yes. Back my ass up.

Back it up. I get yeah. So is this only the this Husky stuff, is this only installed if you're doing their migration

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

folder? Can you start a new folder and just do a VP create for us? Let's kinda, like, walk through what it does. Because I thought you could choose whether or not you want hooks.

I will say, though, I am a fan of Git hooks, especially on open source projects. I know not everyone is. They, like, like, depend on CI, but I I like to make sure my stuff is good before I push up to CI.

Yeah.

Yeah. They can get annoying sometimes, but I I do I do like them as well. Oh, see? VPNNET. Nothing. Right? VPNNET. VPNNET. Interesting.

VPNNET.

Come Come on. You gotta have an alias there. Yeah. Alright. Sanity asks you, do you want a v plus monorepo, an app, a library, tanstack start, or other? Interesting. Cool. So the monorepo stuff, we haven't talked about that yet, but, like, this is a huge use case for it, which is Yeah. I I want a monorepo with tasks and and a complicated setup. So, let's just go regular. Let's, oh, let's do transact Scott.

Pnpm, Yarn or Npm. Obviously, PNPM.

It asks you which agents files you want, which is really cool, and I did find that, both Claude Node and Cursor did a fantastic job at immediately just switching over to using all VP commands, which is amazing because six months ago, I could not get the thing to use Pnpm for the life of me. Yeah. Maybe honestly, it's like the VP command is different enough from NPM instead of PNPM that it's like, oh, yeah. I can do this. It adds a Versus Node folder, which is just for some, Versus code extensions. And then do you wanna set up pre commit hooks for running formatting, linting, and type checking with auto fixes? So this is when you you go ahead and do that. So Wes, then it goes ahead and scaffolds out your whole project.

What would you like to name it? Tan Wes.

What do we want? Deploy to let's do Netlify.

And then this this is no longer the v plus. This is now Yeah. Node we're in Sanity. Yeah. I'm just gonna keep hitting enter.

Now oh, now we're back. There is already an agents dot MD file, so we'll merge it.

Boom. Boom. Boom. Interesting. Installing.

And this is awesome because this is this is kind of what I wanted for for super long. I know there's lots of, like, Npm scaffold out commands, but I I have, like, it almost burned into my brain, which is npm init, npm package set type of module, so it's not Wes m, npm install v, you know, like, I it my, like, my terminal almost knows exactly what I wanna type every single time. So alright. Here we go. By the way, this is an example of why I will not leave warp.

You see how warp is is suggesting to me what I need to put in here? It knows. Everybody who's a warp hater doesn't know the the beauty of it having context for its suggestions.

That's exactly what I wanna do. I'm not a hater. I've I've just never gotten past the login screen. But if I did, this is It's not. It's just how I haven't had login screen for, like, a like, a year. I'm out of the loop. Yeah. They lost me. I don't wanna be a hater no more. Yeah. I I like I like Warp.

Big fan. There we go. So, like, I just created it, and now I can just type, like, VP check or, VP what do we got here? There we go.

Look at all these errors formatting issues found, and I can run, like, VP check fixed, and it will go ahead and fix it. You make a commit, it will rerun those all.

Yeah. And I I just wanna 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 to validate itself. Like, even this weekend, I found myself every new project I wanna do, I gotta set all it up again. I start I made, like, a starter kit, but Vite plus makes that so simple. Like, you 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 the stuff right. Yeah. So it it is nice for for starting a project and then just throwing an agent at it. It's 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. Yeah.

So it's so nice to, like, have a non AI make your scaffold out your your choices initially.

Node repos. So this is this is a huge use case for people using NX or turbo Deno, something like that. So they created their own task runner. So if 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 dot JSON. You run something, and it needs to, like, run build in two others or, like, run a lint on one of them.

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 just, 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 to something like this. Yeah. And I like turbo repo, personally. Yeah. 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 Bos because I just

I was very confused at many times. I I I actually very recently frustratedly ripped out a monorepo because I was so annoyed with it. And and this, hopefully, I haven't gotten my hands on this tool specifically yet to to give it a 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. Yeah. I've been using PNPM for monorepos, which which is fine because, like, it it has a parallel yeah. It workspaces. It has parallel task runner. I haven't tried to do this like, one task depends on the other with PNPM. 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. Mhmm. And then it's like every new agent has to figure out, oh, I should run ESLint before I run type check. So having the depends on seems seems really great.

Yeah. That does seem great. I really just hate installing dependencies in a monorepo.

It's like that's such a That that's that's another thing that they have here. Right? Here we go. If if you run VP run whatever, it will run it in the, like, main package. But if you wanna run, like, let's say you wanna run dev just in, like, your admin package. Right? In this case, you just type there's at my forward slash utils, or you can run, like, filter as well. I had quite a bit of filters with with with Pnpm Yeah. In my package, JSON as well. I still find that to be obnoxious.

For me, I was just like I I ripped out a lot of my Turborepo stuff, and I just replaced it with just Npm 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 and dev tool. That's what Vite is. Right? So it will simply just use that. Vite Wes also announced, which now uses the I think it uses roll down by default, which is their Rust based implementation of roll up. Yeah. Because watching all of this, V eight came out.

So Yeah. Which uses roll down by default.

Pretty great. Task caching is is is a huge one as well, when you have, like, long CI builds that maybe have, like, lots of images or or CSS sheets that need to be bundled.

You can cache the outputs of your, like, Vite 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 it simply just speeds up your deployments. Right? If you have I don't know. Like, in my course platform, 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 or Wasm things where there's maybe two or three megs worth of something moving around. Mhmm. So that speeds up your builds quite a bit. And this is a big reason why turbo repo was so fast. Right? Yeah. The turbo repo was awesome for this type type of thing. And then I know n x has their own. The other thing that this v plus has is like a like a binary runner. So if you use, like, npm x,

you simply just use v p x as well, and that will will run those packages for you. 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 I 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 they're running these quality checks after everything.

But if 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 Wes, or do I need to rerun ESLint, or can I just say use the previous output because nothing changed? So, like, this would also speed up agent workflows because yeah. That's huge. Yeah. You're right. And especially when you're sitting there waiting for the agent to spit it out, and it's like, Node let me just type check the entire project before I go, like,

you changed your markdown file. You know? Exactly. Only preexisting errors. That's my favorite response. You know? Yeah.

Yeah. Only preexisting errors.

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 toolbox?

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 bummers to me is that the framework and plug in 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 in 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. And that makes me sad because I would love to just rip everything out. And there's some issues about the plug ins 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 ESLint and Prettier 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 ESLint and replace all my stuff. So I will be using this going forward. I'm very excited for it. And the only thing I wish I could have with this is a time machine where I could go into the future Wes I'm not going to have to support all of these things. Yeah. So

there I'm just looking at it what ESLint supports.

And is that the same support as their their formatter as well? It didn't look like it on the list. No. Linter the Linter supports JavaScript and all of its, like, TypeScript, whatever, JSX and TSX, and then, like, dot Svelte, Vue, and Astra files, but only the script blocks. So we're not we're not talking, like, the actual HTML part of it. Right? Correct. But the formatter does support CSS or whatever. But, like, you 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 they essentially need, like, an 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.

CJ,

what are your thoughts? Final thoughts here? 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 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 gonna have to figure out what my preferred aux lint and aux format setup is because I'm coming from the world of Antfue's ESLint config, which includes ESLint stylistic, and I have to train myself out of that and use the formatter instead. So there's just some some personal issues I gotta work through, but Yeah. Otherwise, like You got issues. I got issues. Otherwise, this seems great. I I think, any new project I spin up, I'm gonna give this a go first before trying to build out my whole stack or use some starter template, for it. Yeah. I agree. Like, for new projects and, like, small projects that I've moved it to,

absolutely awesome so Yarn. 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 gonna take a a bit more. And not to say that we couldn't use v plus Aspects of Yeah. Yeah. The rest of it, just not for linting and and formatting. Right? They can still use the 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 with this stuff becomes much easier in this ecosystem.

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.