Migrating from Create React App to Vite

I was really happy to discover Vite so I don&#x27;t have to change the way my whole app works with Next.js. Here are the differences I found from Create React App:<p>* It does not have the overlay that warns you about eslint errors in your app; you can bring that back with the `vite-plugin-checker` plugin if you want.<p>* Running `vite` in IntelliJ with `npm run dev` will not show console logs in the IDE[1]. You don&#x27;t need any of the solutions in that thread, though: just use a debug config.<p>* You can add TypeScript types to your env vars with vite-env.d.ts.<p>* Imports have to end in .tsx apparently: `import Foo from &#x27;.&#x2F;components&#x2F;Foo.tsx&#x27;;`<p>* No process.env: Since your code is running in the browser rather than on a Node.js server, there is no process env var.<p>* Network tab shows a request for every file on initial load: This is because each file is treated as an ESM module for hot reload. I couldn&#x27;t figure out how to suppress these messages. It won&#x27;t happen in production since they still use a bundler in prod to save network round trips.<p>1: <a href="https:&#x2F;&#x2F;ww.reddit.com&#x2F;r&#x2F;react&#x2F;comments&#x2F;zo6nay&#x2F;how_can_i_view_console_messages_in_terminal_when&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ww.reddit.com&#x2F;r&#x2F;react&#x2F;comments&#x2F;zo6nay&#x2F;how_can_i_view...</a>

We maintain a fairly large and complex CRA application, which has been migrated to Vite, but not fully.<p>Since a lot of changes would be needed and we are very risk averse (heavily regulated industry), we decided to do it piecemeal by first configuring Vite to behave exactly (or as close to as possible) like CRA and later removing these Vite configurations one by one (and making necessary code changes).<p>Currently our production builds are done through CRA while dev runs Vite. It works really well and minimal code changes were needed.<p>I&#x27;ve been wanting to release this config publicly to help others migrate to Vite, but have unfortunately not had time to.

When I switched from CRA&#x2F;webpack to Vite I saw an order of magnitude speed-up, from minutes to a few seconds to compile. My laptop is old, needs replacing and starting to struggle but really shows how bloated webpack is.<p>It&#x27;s fairly trivial to switch too, though means you need to start understanding how webpack&#x2F;vite&#x2F;package.json&#x2F;tsconfig actually work. I did the same as the author and just made a new vite app and then copied stuff over and moved things as required.<p>The only complication I could really see where the environment variable names, which we only used two anyway.<p>By the way, I don&#x27;t know why the author changed to using import &#x27;components&#x2F;blah&#x27; to &#x27;~&#x2F;components&#x2F;blah&#x27; as there&#x27;s no real explanation in the blog post. The link for their commit is broken so can&#x27;t see what the author has done.<p>You actually don&#x27;t need to do that, all you have to do is set &#x27;baseUrl&#x27; in your tsconfig (e.g. &quot;baseUrl&quot;: &quot;.&#x2F;src&quot;). That tells typescript where to look for imports. Then Rollup via Vite handles the rest in compilation.

We recently migrated a Laravel app from Webpack (Laravel Mix) to Vite and it was mostly painless. Like OP, we had to update some imports that were using require and we also have a few different entrypoints which is not that well documented for the Laravel plugin.<p>Another issue we ran into was certain dependencies that only have .cjs versions that work fine when building, but during dev would fail to import via ESM correctly (the dependency itself is inside of a lazy loaded component). That means that if we&#x27;re working on that part of the app, we need to do a full production build (6 seconds) between each code change and then use the prod build locally to test the feature. Annoying for sure but we can live with it until someone has time to update the dependency to one that natively supports being loaded via ESM.<p>If anyone is running the old Laravel build pipeline, I suggest upgrading now because it&#x27;s potentially only going to get more and more complicated. If you have a simple frontend with some helper functions or a few Vue components, it should be pretty easy to reason about. The course on Vite from Laracasts was helpful to explain what some of the less documented features are, which was helpful for integrating with our application.

Good read! I have a huge CRA app I maintain at work, and we&#x27;ve been wanting to migrate to something else for years now. will have to check this out.

Both CRA and Vite seem to be a mess, I don&#x27;t know how people work with that.<p>My recommended stack: node, npm, typescript and esbuild.

I’ve recently discovered rsbuild, which doesn’t have vite’s issue where a large application with many small modules takes minutes to load (in dev), because all 6000 files are an individual request.

CRA seemed near-abandoned when I first tried it in 2020. I&#x27;m surprised to hear that people are still recommending it as the default. Vite works so well out of the box.

It&#x27;s easier than people think, and it&#x27;s very well worth it. CRA is now obsolete and not getting any updates. Vite is so much faster as well (code changes reflect immediately).

How is Vite compared to Next with static export? I moved my React apps over to Next earlier this year and I&#x27;ve been pretty happy.

CRA is meant as a starter application. IMO for anything serious, an app should either &quot;eject&quot; or use a framework.

Surprisingly painless, in my experience. Vite is good.

Preact with Vite works very fast and Preact seems like a good long-term solution for projects which will use the single-page application approach (React seems to move ever-closer to the server rendering approach).