Noel Minchow: Hi, and welcome to PodRocket. I'm Noel, and today we're joined by Matias Capeletto, or Patak, as many online know him. He's here to talk about the newest release of Vite, Decon, a whole bunch of other stuff. We'll just kind of let him introduce himself, and jump in a bit. I guess, first of all, how's it going? Matias Capeletto: Hey, really happy to be here. Thanks again for the invite and good to be talking back to you. Noel Minchow: Awesome. Yeah, we're excited. Again, our first conversation, I feel like was really awesome. We covered a lot, and it was very insightful. So I'm excited to be chatting again and welcome you back. I guess. Yeah. Again, we got a whole bunch we can talk about maybe, but before we jump into what's new, in Vite 3, we can talk about what Vite is for those who aren't familiar at all. And I guess your role too, kind of, in the ecosystem and how you found yourself working on Vite. Matias Capeletto: Yeah. So first of all, what is Vite. We usually need a build tool when we do applications for web. We don't code in HTML, JS and CSS, but we do use Vue or JSX or Type Script. And we use some high level tools, but the browser doesn't understand any of that. So we need that tool to actually convert all that to something that the browser can run. So normally Webpac was skilled in this space. We all have been using Webpac for a while, but now, given that there are some new technologies available, like all the other browsers, green browser support, ESM modules, and some other things that have evolved, we are able to create some new tooling that allow us to have the faster dev experience and the same kind of production-ready build once you are ready to go. So Vite is in the data space like Webpack, Parcell and these kind of tools. Noel Minchow: Awesome. And how did you find yourself working on this kind of this part of the tool chain? Matias Capeletto: Yeah, so I was working in a project that was using Vite when Vite 2 wasn't released. So I was getting involved because I was hitting the backs at that point that was quite unstable. This was around, let's say, November of just 2020, so sometime ago, and I started to collaborate, other people start to open source that, send in a small pool request or participate issues. This is very useful. You don't need to send a PR to make yourself useful to an open source project. Just sending a very good issue with the proper reproduction or checking the issues of others or getting involved in the community and discussing. So this was what I started doing with Vite. I was also already kind of like talking with some of the people involved like Anthony Fu because of another project you use. Matias Capeletto: So I started to collaborate, and it's like, a lot of the things that happen in open sources, one PR takes you to the next, and then you start to develop a relationship with the maintainers that encourage you to do more. Like normally, they don't push, but it's like they open the doors, let's say. So this is with what Evan did with many of us that were at that point. And when Evan created a Vite team, I was one of the people that were more involved. So, I was part of the initial Vite team. Matias Capeletto: And then other people joined. And I started to take a role in the sense of like handling the releases and talking with people in the ecosystem. I really like this kind of community or ecosystem work. And so this is what I have been doing. And after a while, a Start Lead that is this online IDE that they do web containers and you can run node in the browser with them. So they are using Vite a lot because it is the fastest way to get you a playground to get started and they reached out because Vite is really important to them. So now I'm working full time on Vite hired by, by Start Leads. So this is now the current involvement. Noel Minchow: Nice. Yeah. You said something there about how, when you start working on a project, you said open source, but I think any project, you start with, some little external, maybe one-off bug that you think, oh, this is a simple thing. And then as you fix that, you discover other things and you find yourself going from one feature request to the next. I mean, I think that is insightful. And I mean, not something that people reflect upon a ton because it just kind of happens so organically. But I feel like that does happen a lot. That's how people find themselves in the bottom layers of code base is because they started some little thing on the top layer and then learned why it is the way it is. And it leads them down this path of, oh, I understand that. Matias Capeletto: Yeah. Yeah. More like with projects as big as, as deep, it's not just a library that is a single line utility. But it is quite complex. There is a lot of parts and you can collaborate, just knowing about certain aspects. Let's say after a while you end up fixing bugs in almost all. So you end up checking all the codes and starting to understand how everything fit together. But I, at the beginning its approachable to focus on some of the parts of the project. Matias Capeletto: And I think that there is a lot of, there is the importance of maintainers in how they approach contributors. Because Evan or Anthony Fu or other maintainers from the Vue ecosystem or Vite ecosystem are extremely, extremely good at opening that doors. And at kind of this... Encouragement without pushing. That's very important for others to get involved. And this is what takes later. Like with me and other people that got into the team and now they are 600? More than 600 collaborators to the Vite core and growing. So it, that is one of the quite interesting metrics let's say that Vite core is now a collaboration point for a lot of projects. Noel Minchow: Yeah, yeah. That's always encouraging to hear, I guess. And I could talk about the communication style and the organization layer of open source projects, like to no end probably if we really wanted to get into it. But no, let's talk about Vite because that's probably why people are here. So I guess, what is Vite 3 and why is it a major version, is maybe the first question I'll ask. Matias Capeletto: The main trigger for the new version is that Note 12 is in end of life. So if you want, we were supporting so far Note 12, and if you want to follow Sam with the majors, once you drop an old version and you're going to tell your users, you can no longer use Vite with Note 12. Then you need a new layer. So this is the reason. And you can actually say, okay, I will not follow somewhere. But that is not good. Or I will wait two or three years for the next mayor. And then only drop notes. Let's say 16 already there. The thing is that if it is already in end of life, dropping Note 12 for a tool like Vite allows us to increase the maintainability of the code base because we can start using more modern patterns, like functions that weren't there in Note 12. Matias Capeletto: Some bots are no longer there, so you don't need some hacks or workarounds that we added in the code base to support previous version of note. So it is a good idea, I think, to not be afraid of a mayor version. And more, if you take it in the way we are doing with Vite that we are going to do, at least one major version per year, but we are going to put a lot of care into making these, almost as if you will update a minor. So we are going to try to move the whole ecosystem as quickly as possible. The ecosystem is used with minors, let's say. We obviously are going to take the opportunity that the major gives us to, for example, we have deprecated functions that during the last six or 10 minors, you have been receiving a message that say this option has been deprecated should still use this other option. Matias Capeletto: So a major is a good opportunity to say, okay, all that, the factions are going away. All that worded messages are not going there. You are going to receive a higher error if you use that. That is normally because people use Type Script. What is going to happen is that directly Type Script is going to tell you, that option doesn't exist anymore. But most of the people should not experience that. And it's a very easy, let's say, migration path, because there is a migration guide that you can follow. And one of the things that we say, the first thing is these options are no longer there as they were deprecated and what you should use in any of them. So that, is like something else that we wanted to do. And from there, we had the opportunity to maybe review some defaults, for example, or introduce some breaking changes that mostly they won't affect final users, but these are things that we discover when working with the ecosystem and projects that are using Vite. Like SvelteKit, Knox, Astro, and they, for example, normally they discover that something will be better for them. Matias Capeletto: Like if you work in some other way and during the minors, we probably added an option for them to do that because we couldn't change the default behavior. But once we reach the major, we can say, okay, that option is gone. And actually this is going to be the new default, so that would be kind of like the first part. Then when we are it, it is two months that we did the mayor. So a lot of other opportunities appear, let's say. But we managed to keep, if you read immigration guide, and if you already start to hear how was the immigration for a lot of people, it is like a minor. Matias Capeletto: So, I think it is working pretty well. And we can talk about also Vite ecosystem CI. That is the infrastructure we have to test all the ecosystem projects, also a little bit later, because that is what helped us to release when we are ready. To release when we know that the old ecosystem is ready. And because most users are consuming Vite through a framework, like Well Kit, like Knox, then it is kind of easier because the Vite team and the framework already... Noel Minchow: Are collaborating, yeah. Matias Capeletto: Yeah. Are collaborating and already hit all the issues that would normally user will hit. Noel Minchow: Yeah, yeah. It makes sense to kind of explain it in that way. If your end user pool isn't huge I think there's probably a little less trepidation a lot of the time. And, oh, we have a core. People are paying it. People that are using us or paying attention to our version numbers and they care about new features and staying updated. You've said your guys' release cadence was going to be every year. Do you think it'll be pretty closely tied to the node versions end of life? Is that the plan? Matias Capeletto: That was the original idea that, for example, I think the next one will be in September next year, because they changed it a bit. They moved it to align. Because they also have to align with other things. But actually we made release bit for this year because they, there have been a development that Lucas or Luka, I don't know what's the pronunciation like from the Rollup team. Actually, they are going to release, Rollup stream. And Rollup is half of Vite. It's our main dependency. Let's say, it's what builds your production app. So if we want to update to it, we cannot continue to called Vite 3, we need a major. Matias Capeletto: So, and if Rollup 3 is there and actually it has improvement and the Rollup team is working like, focusing on it, we cannot wait eight months for, or one year, for the next one. So what is going to happen probably is that in one month or two months Rollup will release the version. We are going to wait maybe another month or two for the ecosystem, the Rollup ecosystem of plugins to actually see all the bugs, and update to support it. And once we see that the Rollup ecosystem is ready for Rollup 3, we are probably going to produce another layer of beat. Noel Minchow: Yeah, that makes sense. Can you tell me, I guess let's get into the ecosystem CI that you've touched on briefly there. What is that? How does that work? Matias Capeletto: Yeah. So there is, this Dominque G. That is from the ecosystem. He has been working on Vite plugin as well. That is what powers the integration between Vite and SvelteKit. And we worked with him to create. It is a repository with actions that every major project in the ecosystem have a test definition that connects their CI to Vite main. So what it happens is that every Monday, Wednesday, and Friday, in a channel in our Discord, in Vite Lab, we receive how the main branch from each project in the ecosystem, around 10, there are right now, how is the state of that against the state of wind main? So if we see that everything is green, we can be pretty confident that not only our tests are passing, but the changes that we did are not producing our regression on any of the CIS of the ecosystem. And that is quite a net. Noel Minchow: Yeah. That's interesting. Matias Capeletto: Yeah, yeah. This is something. And once we get our red, we actually use the same thread in Discord to talk with the maintainer and say like, look, we found this red, what do you think it is? We exercise with them the error and we correct it before releasing. So this is why we started doing this maybe five or four months ago, and it completely changed how we released and how we work. Because before I was mainly pinging, like the maintainers saying, could you please test before I release? Because I'm afraid that I could break you. And now we have a great overview of the state of the ecosystem and we can press release button, with confidence. Matias Capeletto: So this is something that happened in Vite 3. For in Vite 2, we were totally green. And it was very good to do all the minors and patches. When we started working with Vite 3, we got all reds because we started to change some breaking changes, some like moving to DSM. There were some big changes, but we work it with them until that was green. And most of these projects actually created some Vite 3 branch. So they could keep going into the main development. And at the same time already, start testing Vite 3. So what we were testing was like this, like the Vite 3 branch in the project against with main, and it has been working very well. Other projects like Knox as well, Astro, they want to do the same now. Like Dominque G at one point is going to work on abstracting this in a package that other ecosystems can use, because they see the value and they want to do the same with their downstream dependency. Noel Minchow: Gotcha. So, so just to help me understand this repo with the actions that are performed, who is maintaining the actions for a given downstream dependency? Are you guys writing that? Or are the maintainers of the downstream? Matias Capeletto: Each of the definitions is like five lines of code. So it doesn't matter that much who maintains, because it is mainly saying this REPA, for example, Astro, with this branch, the Vite 3 branch, and for building, you need to run this command that normally is built, that is their fault. For testing, you need to run this command that normally is test. And that's it. It's already, this Vite CI knows if you're using yarn, PMPM, do the proper override. All that is taken care of. We try to involve the maintainers because it is very important that this is something that we do together. So normally we don't add another project, even if it is only that five lines and we could have. But wait for the maintainers to kind of like do a PR and know how this works. So actually most of the project were added by the maintainers themselves. Noel Minchow: Got it. So, essentially what the repo is doing is like for a given consumer, because they are an open source project for the most part as well, you know how to pull and run their test suite. So you're taking the project building, running the test suite, but using whatever version, whatever is the master or main version of Vite. So you can tell when test break, is that? Matias Capeletto: Exactly, yes. And now, all major package managers, like MPM, Yarn, MPM, PMM, they have support for overrides. So it is quite easy to do that, pointing to Vite. And in some projects it's a little bit more complex, because for example, for the plugin view, we also point to the latest of the plugin view. Or for as well, it is going to two separates repost and getting the latest of the two separates repost against domain. Matias Capeletto: But it's mainly testing. Being able to on-demand and kind of like in a cadence, be able to see the state. Because we use it on the manual. So if there is a PR that is a little bit involved, we can run Vite ecosystem CI not only RCI, like just by pressing a button. So if, for example, now we have to release a patch for Vite 3. And there was a PR that I wasn't sure. So we actually run not only R CI, but we run Vite ecosystem CI and we see that everything is green. So we are more confident that we can merge that PR. Noel Minchow: Nice, nice. Yeah. That's super cool. Yeah. So, was that a pattern that you've seen anywhere else? Anything inspire you guys? Or is this a pretty new idea? Matias Capeletto: I know that the Vue project at one point, like Solitaire, I think, put something in place, but I haven't seen the exact same set up that we have now. GitHub actions are also, it's not that new, but they were not there, I think, when the View ecosystem was doing this. But I hear that now, for example, View wants to do the same also as a lot of maintainers are sharing and we see the value. So they also want to do the same and it will be good because if you read some new view version, it will be good that you check the KNX CI before. Noel Minchow: Yeah, that's awesome. So, yeah. The peace of mind that must grant sounds yeah. Like super. Matias Capeletto: It is, it is. It was like pressing the button in the dark before. Noel Minchow: Right, right. Yeah. Much less scarier to hit the publish, the deploy button. Yeah. So I guess that does, I think this is kind of tied to this anecdote that we were just talking about before, but in my head, as a consumer of NPM packages in general, I feel like what I usually think about when I'm doing a major versus a minor upgrade to a dependency, is that like how it's going to interact with my peer dependencies is a lot, or it's peer dependencies is the thing I have to think about a lot. Right? If I'm upgrading a package, usually the package itself isn't that hard to upgrade. The challenge is then the interaction with its peer dependencies or other things in my project. Does Vite have many peer dependencies that your guys' like downstream consumers are using? Or are most of them just using Vite and that's kind of all that they have to think about? Matias Capeletto: Most, if you are just using Vite, it is like the complete package. So normally you only have to think about Vite. But most users, as we said before, they don't use Vite except for playgrounds or something small. Normally, for example, if you like Svelte, Svelte recommends that you use as SvelteKit right now. So, and if you use Vue, there is two options Vue recommends. Like with create Vue is a Vite power starter that is, has only view router and very little opinion. But a lot of people that wants to do a larger app are going to reach out for Knox. So a lot of people will hit Vite, through one of these dependencies. And they're going to wait a little bit with Vite 3 because it is the dependencies that even if they are all green now, they are going to be in the following weeks saying, okay, now you can use like this. Matias Capeletto: For example, Astro yesterday marched the support for Vite 3. Knox I think was two days ago that released the last RC that is based on B3 as well. Kit started to require Vite 3, I think three days ago. So it's being quite swift the movement because of all this prior testing that we did, no? And prior work that we did with them, but still is not instant because they need a few days to do all the arrangement. Noel Minchow: Yeah. That makes sense. So say I'm a consumer. And when you say, Vue recommend the Vue CLI presumably, is that for? Matias Capeletto: It's not Vue CLI because that one is based on Webpac still. And, but there is a new project that is called Create the Vue, and it, yes. It is what you get, when, for example, you go to the official view documentation right now, or you actually go to your consult and say, "PM PM create Vue." If you say that, that is going to hit the create Vue package. So that is going to start like some prompts that is going to create a Vite power up and is going to do a lot more than the normal Vita starter, because ours is a very bare bone, more to test Vite than Vue. Matias Capeletto: This is a proper app that has, is going to ask you if you want to use routing and add for you, your router, if you want to have testing and add for you Vue test. If you want to have end-to-end already and add Cypress for you and already configure LinkedIn creature, all these kind of things. It's still quite bare bone compared to something like KNX or VelKit that already have tons of opinions about how you should structure things have features like content and some other things. This is still on the bare bones side, but already you get a proper production application with testing with LinkedIn, with everything done. Noel Minchow: Nice. Yeah. It sounds like you're saying, because such a high number of the consumers are consuming it via a package, like via Create View or Nuts or something like that. They're just upgrading that. Once their upgrade to the new version of Vite looks like them upgrading whatever they are depending upon, and then they just get it. Matias Capeletto: Yeah. Upgrading KNX, upgrading as well, kit. Noel Minchow: Yeah. That makes sense. Emily: Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you there would be no podcast. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right. Back to the show! Noel Minchow: Let's talk about features a little bit. Is there anything new that end users might benefit from with a version upgrade like this? Or even just performance increases? Or what's the most exciting? Matias Capeletto: Yeah, we can talk about first about the what you see first. That is like the new documentation. So this is like we are using Vite press. This is a project that started after. It is like the next generation of Vue press that this documentation generator. And, but instead of basing it on Webpac it's based on Vite. And it was very interesting because he did it as a way to test Vite, and also as a way to generate the documentation for Vite. And it was this dog fooding that was going in place that this dog fooding is like running now in the project, full swing, because we are also using Vite test to test the internally. So we, in the Vite project, we have Vite press to generate the docs and we have Vite test to test. Matias Capeletto: So it is like a dog fooding, meta going there. And so they are about to release the 1.0, and they are in alpha right now. And one of the main features of this new release of Vite press is a new theme. [inaudible] that is a view core contributor has been working on this team for a while. And it has the most support. There is a lot of little details improvement. There is a team page now, there is support for a lot of things. So if you go to Vite in depth right now, you're going to get a dark SIM. If you're already in your system, it's dark. And it looks a lot better than before. And we also updated the templates that we have to look like the docks. So if you go to vite.new, for example, that is going to open as stack list playground. Matias Capeletto: Now it will all look very similar to the docs, but you're going to see some dark mode. It's nice because we are starting to receive the issues report with these new templates that looks better than before. So it's good and we are working with them now. And then when you execute Vite, you're going to see the CLI is a little bit nicer. Before, we have more. The colors are more on brand, let's say. They're a lot of little details there. We changed it, the port. So instead of starting at 3000, you're going to see that Vite will start at 5,173. That is a specific number. And this, we needed to change because there is a lot of tools that started 3000. Actually our review server before had started at 5,000 and Mako S decided to take it. Matias Capeletto: So, we got a lot of angry reports saying that feed preview wasn't working and in Mako S. So now it is going to be like 5,173 for dev. And then, in Vue is 4,173. So this is one change that shouldn't effect much, because normally what you do is clicking on the link that the CLI will give you saying, okay, your dev server is ready here. Like, chef open it. So it just port change. Matias Capeletto: We were able to actually get faster at call start. We already did some improvements in 2.8 and 2.9 related to call start. This was mainly because when would you have dependencies, like Lodash, that has tons of little files. If you give that to the browser directly, the browser will need to load tons of little modules. And one of the issues that we have with the way Vite works is that if you give the browser 2000 modules, even if it is fast to process each of them, the browser hit a bottleneck. Matias Capeletto: Normally, you don't hit it because you have your application, code is split. And normally you load around 100 modules or something like that. And that is totally, totally fine. But at the dependencies level, you may hit this issue a lot sooner. So one thing that Vite does is pre-optimize the dependencies using ES build. And ES build is a very fast go bundle that we use all over the place where we need a speed in Vite. And we are pre-optimized these dependencies. So loaders will be a single file. View will be a single file. And then all the common dependencies between them will be chunks between them. And you will then end up loading only a handful of files for all your dependencies. But this process of preventing before was done, like kind of blocking. So what will happen is before the servers start for the first time, it will actually need to scan all your files to check and discover the dependencies and then optimize them. And then the server will start. Matias Capeletto: This will be cached. So if you don't touch your pack adjacent, that was normally what happened, until you add the next dependency. Then, the next time Vite will start will already have this cache and we'll start right away. But call start is very important. For example, for opening online, in established, it's very important because you're always a caller start. You don't have the cache there. So it is an important use case to have a fast call start. And in 2.9, we're already starting to move the scanner and the optimization step, like after the server has started. So doing that in parallel, we had some improvement there, but in Vite 3, we were able, we have more information because of some architecture changes that we did. Matias Capeletto: So one of the problems that we have is that if the scanner will miss one dependency, you will actually need to reload the page. So in caller start in Vite 2.9, it could happen that you would start your application, and in the middle, it will reload. And then start again. So this only happen in caller start, but that reload could take the time, like double. Yeah. Matias Capeletto: And this was some edge cases, but not that much because it happened when a plugin will inject and import, and this is something that the plug-in ecosystem is starting to do a lot. So it's kind of important for us. So in Vite 3 that is solved, and we are able to, most of that is gone. And Vite will start without those reloads. So for a lot of application, for example, like lateral, that is like storybook, Vite native, alternative. He tweeted, I think yesterday, that for them Vite 3 was double caller start. Like double as fast. And this is just because they were hitting always one of these full rollouts. So for this tool in particular, like Vite 3 is twice as fast. Noel Minchow: Nice. That sounds super handy. I'd never run into that issue before with any of my products, but they didn't have a ton of dependency, so that was probably what they were a little. But yeah, I can imagine. I guess, was handling that case, was that a pretty low level, tricky change to make? Or was that, once you guys were aware of it and figured out what was happening, was it pretty simple, but it did require a major change to get fixed? Matias Capeletto: The latest part of that change wasn't that big. But to get there, there were lots of groundwork being done from 2.8 till now, to make sure that we are able to do all this in parallel to wait for the dependencies to be optimized, but in a more lazy way. So there was a lot of work done there. And actually it was finally enabled by some changes with data at build time that we can also talk about this. It is experimental because we didn't have enough time in Vite 3 to actually test it enough with the ecosystem, to be sure that we should release it, but it is working. And some project will already swap to it. And we are going to review if we can enable by default in Vite 4. Matias Capeletto: And this is the idea that we, one of the most important, bots for us is the ones relating to differences between the dev environment and the build environment. This is extremely important because if something works in dev, and then you go to production and it doesn't work, this the worst thing that will happen to a tool like Vite. Because your users are going to lose the confidence that. Noel Minchow: Yeah. Right, right. Matias Capeletto: That the dev environment is giving you, like a good picture of what is going on. So we have, how we handle dependencies right now is that during Dev, we are doing this optimization. For example, for our dependency, like react that right now is common in Cypress only. So we need, in roll up, to be able to load it from an ESM contact. So, in depth, we are doing this dance that I told you about the optimizing the dependencies with ES build. Matias Capeletto: But during build time, we are not optimizing the dependencies. We don't have the bottleneck of the browser there. So it is a relapse itself, the one that goes over all your dependencies. And for common JS dependencies, like React, there is this big piece in the ecosystem that is called Rollup plugin common JS that is in charge of like taking this common shade as dependency that is react and doing the interrupt so you can actually import, name it, import from there. Like, import, user state, and everything from react. And so this is like a, quite a difference, let's say. We care a lot. And we like, if there is a bug it's going to be squashed pretty soon there. All the pieces are quite robust right now. But if we could actually remove from the picture plugin common JS and during production optimize your dependencies in the same way we do during Dev, that will remove a big difference. Matias Capeletto: And because we had in the past bugs that were, this dependency doesn't work in plugin common JS because there is an issue with CLI dependencies or something. Normally, the product team will be very swiftly corrected, but it will be interesting to have that the same. And this is one of the experimental features you can already play with it. That you can enable optimization of the dependencies with ES build during build time. This will also make, because they are cache, it could make your build more, have a speed up, let's say. Because, it's the same as in Dev. We are going to grab all of that load dash, and I can pre-compile it, and then Rollup will have to do less [inaudible] in there. And we are using exactly the same interrupt in both. But we need to check. The main issue we need to review now is like how three shaking in this new world works because roll up using plugin, common JS is extremely optimized. Matias Capeletto: They're the same people working on both projects. And three shaking works extremely well there. But now we are pre-compiling your dependencies with ES build. And we need to check that roll-up is going to consume that new structure and be able to, in all cases, properly three shake it. Not for production, but it is extremely important. So this is something that in the next months we are going to explore with ecosystem. I expect and hope that some of the project will already start to be great, like Knox or SvelteKit. Pull for you, the site that the best is already to optimize your [inaudible] into your own build. Because it is an option now, so they can use it. And then if we see that all the ecosystem is already there for Vite 4, we could make it the default. Noel Minchow: Nice. Yeah, that makes sense. So I guess just to take a couple steps back. So with, with Vite 2 was ES build already the default? Matias Capeletto: It is like we are using this built for, let's say, a lot of things. Apart from optimizing your dependencies this built is used for transpiling individual files. For example, if there is JSX, or if there is Type Script, esbuild is going to be used to strip the types very quickly. And we are also using it as the default minify for both JS and CSS right now. So beforehand, I think around 2.6, we immigrated from Terser, that is another mini file, but is in, right in JS. So this esbuild is a lot faster. So, the build is based on roll up, but where there is something that is quite intensive and esbuild can do that job, we are using esbuild. Noel Minchow: Got it. Got it. And, and was that like at dev time, was that, I guess, the build step aside where it's in the experimental feature, did anything change there between Vite 2 and Vite 3? Did the defaults change? Or was that how that had always been working? Matias Capeletto: No. Now, because we decided to kind of leave it as an option, it didn't change. Your builds will still use plugin common JS, but there is an option that you can see in the immigration guide, what you use. And it will avoid using plugin income JS and start to optimize your dependencies during build. Matias Capeletto: And so you will get this world, this new world where it, the handle of the dependencies is exactly the same between dev and prod. But at least for a while, until we decide to make the default, you should watch out how three shaking is working for you and this, and help us, no? It is quite important for us at this point. If you test this, give us feedback. Both, if it is negative, because we can get a report and fix it, or if it is positive, because normally we receive a lot of bad reports, but it's really good. If you did immigration and it worked it well, I don't know, tweet about it. Or go to Discord and tell us because that is very useful information to know what is the state of the ecosystem. Noel Minchow: Yeah. And I have a feeling, it probably can help as well that you know certain configurations don't seem to be generating problems and these do so you can figure out where that Delta is. Yeah. Can be really tricky without the positive signal and only the negative signal. Are there any other cool experimental features? Matias Capeletto: Yes. There are two more experimental features. One is quite low level that is about improvement in hot model remote. Like one of the main features of Vite is that hot model reload works extremely fast. This is quite important because of the feedback loop that you get. But how it works in Vite 2 is that we have a model graph of all your source code, let's say, on your dependencies. And, but the relationship between the models are only this module imports this other module. So, and there are some sub models. For example, if you import a view file, then there are three sub models because we have three parts that can play the script and the CSS. And some of them act differently. If you change something in the CSS, ATMR will be faster because you only need to swap a style. Matias Capeletto: So, there are some things that are different there, but it is at that level. But there are some projects like React and Svelte now that they are also exporting from the same file, like other functions, let's say. And if you modify one of these functions, maybe you don't need to reload the full component. So the current relationship that are recorded in the model graph are not enough to say. Like, if I am importing the component and importing a new deal, then I need, or not to hold model right now. Or, where you need to put the boundaries. So this is a feature that Ritso, they work in Vite as well. This is, they did the initial implementation of the VE called model reload part. And they actually did the proposal, the PR everything. Matias Capeletto: And now there is an option that if you enable, it will give you a richer module graph that has all this information and projects could use that information to have more fine grain control over when your application reloads and how. There could be a small performance penalty during Dev, because of all this extra information that is recorded in the graph. So it is not enabled by default right now. And it's something that, because that is also experimental, we are going to explore with ecosystem, see how many of the projects end up using this, and if at one point, we see that everybody's using them, probably it will be the default. And if we see that the performance is not that bad, let's say, because something that is important for us is that if Vue, for example, is not going to use this, you shouldn't pay for this extra information to be there. Matias Capeletto: And so that is one, and then there is another one about we work it during Vite 3 in supporting relative base that normally when you build your application, you know what is the base where you're going to put. Imagine you have a domain and okay. And we have, let's say your domain and you have some path to get your application. So in real time, you are going to actually generate that path. Matias Capeletto: With relative base, you are able to generate something like a distribution that doesn't need to know where you put it. So you can put it in a pseudo domain, in any path in your domain, or in a network, like IPFS, and their experimental feature about that. And some other important things. I think we should at least touch, like bundle size production. We got minus 30% there in the publish size, then there was a massive effort by Blue and Saffi and other team members about working through the open issues. We had 770 open issues. And now, after this release, we are around 400. So it is amazing the work that was done there, too. And this is not only closing, there is a lot of very small fixes that at the end of the day, like remove a lot of these little cuts that are very important in these tools. Noel Minchow: That's a lot. Yeah. I'm sure. It sounds like there's been an immense amount of work going on. But yeah, I want to make sure we have a little bit of time to talk about Vite Conf. What's going on? Who's talking? Plug it quick. Matias Capeletto: Yes. So once I joined STS, one of the first thing that Eric Siemens, the CEO of the company told me is, what if there is a Vite Conf? And StackBlitz is hosting this year, at least of the conference. And already with other community partners. And we are starting to touch base with people in the ecosystem. We would like to give talks and starting to discipline, to shape up in around March this year. And there was so much interest to get this going. And it's a very interesting conference because I think that the Vite part is going to be around, let's say 15% of the conference. And then the rest that is like 12 hour of content is going to be about the projects. So as Rich Harris is going to do a Svelte talk, Ryan Carniato is going to do a Solid star talk, Evan will be there doing the Vite Keynote. Matias Capeletto: We are going to have there is going to be [inaudible], Astro, all the projects that are using Vite that are a lot of them. We can talk a little bit about the ecosystem at one point. But so it, I think it's going to be a really interesting conference in that regard. We're going to have some live panels with the maintainers of this framework talking together and another one with the team. The Vite team talking about the future of Vite. Matias Capeletto: Yeah! Go to viteconf.org to know more. There is some cool ticket generation after Euro sister, you can choose the theme of your, for example, you can have a SvelteKit ticket or a Vue team ticket and then you can share it. It has been pretty nice during this week that we launched it to see the different communities, sharing, let's say like, "The Vue communities here, and we're going to Vite Conf - fun!" So it has been quite interesting, the reception so far. It was launched, I think, four days ago or five days ago. And we are about to hit 4,000 registration. Like tickets generated. It's important, I didn't say, but it's a free online conference. So everyone is invited and we hope to see you there in Discord chatting about the stream and also watching. Noel Minchow: Hanging out. Yeah, we'll be sure to get a link to that in the show notes. Is there anything else you want to plug or send listeners to? Matias Capeletto: I think we say quite a lot, go to Vitejs.dev, and see the new documentation. And tell us about how Vite 3 is working for you. Go to Vite.new and test it as usual. It is the best way to know how Vite works. And yeah. Register for viteconf.org, because it looks like it's going to be quite an interesting event. Noel Minchow: Yeah. And check out Vite press. The new version looks great. It's so nice. Yeah. The new theme is beautiful. Yeah. Thank you. Thank you so much for coming on and chatting with me. It's been a pleasure as it was last time. It's always been awesome talking. Matias Capeletto: Thank you so much. Kate: Thanks for listening to PodRocket. You can find us at @PodRocketpod on Twitter, and don't forget to subscribe, rate, and review on apple podcasts. Thanks.