10 ms·

Migrating from Create React App to Vite

60 points by luu 2y ago

danielhep 2y ago
Good read! I have a huge CRA app I maintain at work, and we've been wanting to migrate to something else for years now. will have to check this out.
- tuyiown 2y ago
  beware for large apps, if you don't have heavily splitted your app with dynamic imports, vitejs is frustratingly slow by loading each ESM module separately. Seems that rspac has others interesting tradeoffs. Works great once loaded though.
  - iliaznk 2y ago
    We have encountered that problem too. As far as I learnt from various sources that is caused by circular imports in some cases, and by using index files that re-export your modules in other.
- dangsux 2y ago
  [dead]
  - Vinnl 2y ago
    It hasn't been maintained for ages, so at some point you'll want to use some new dependency and find out that you can't. And it's very slow, too, if I recall correctly.
  - chrysoprace 2y ago
    Not OP, but we had issues with SASS that made it difficult to upgrade. It didn't like the M1 architecture when trying to upgrade from Node 12 to Node 18, where as swapping it out for Vite just worked. Given CRA is deprecated, it made sense to move away. I followed a guide[0] which covered most of the things I needed to change and the remaining issues just involved following the build errors. We also saw much-improved build times, which was a welcome change. [0] https://cathalmacdonnacha.com/migrating-from-create-react-app-cra-to-vite https://cathalmacdonnacha.com/migrating-from-create-react-ap...
auggierose 2y ago
Both CRA and Vite seem to be a mess, I don't know how people work with that. My recommended stack: node, npm, typescript and esbuild.
- mattmanser 2y ago
  Vite is great, don't know why you'd make your own life hard like that.
  - auggierose 2y ago
    On the contrary, this stack makes my life as comfortable as possible. I do understand esbuild, I don't understand whatever it is that Vite does.
    - lyxell 2y ago
      With Vite you do not have to hack together Hot Module Reloading yourself.
      - Aldipower 2y ago
        Thanks, so I won't use vite. Hot Module Realoading never worked reliable to me.
        lyxell 2y ago
        I can’t speak for how it works in other frameworks but HMR for React works flawlessly in Vite.
        conradfr 2y ago
        Because you did not use Vite.
        homebrewer 2y ago
        CRA's HMR is a mess that breaks more often than it works, but I haven't had any problems with Vite's HMR after using it for the past three (I think?) years.
mkhalil 2y ago
CRA is meant as a starter application. IMO for anything serious, an app should either "eject" or use a framework.
- nayroclade 2y ago
  CRA seems pretty much abandoned. I wouldn’t recommend it for anything nowadays. There are much better options for both starter and serious apps.
- JoeyJoJoJr 2y ago
  I would never touch another project that has ejected from its build tool, and I am almost certain that I would never do an eject on my own projects. The maintenance burden is too high and it always becomes a complete mess as dependencies go out of date. I’d be interested to know for what reasons others have ejected? I have worked on 3 projects where some idiot dev had ejected for the silliest reasons. Since holding firm on my “never eject stance” I’ve never encountered a problem that I couldn’t solve without reading the docs more.
  - williamdclt 2y ago
    I’ve been unhappy with both options. Ejecting gives you an incredibly complicated configuration (as CRA needs configs that can handle _any_ project) with a high maintenance cost as you say. Not ejecting gave me other headaches. Any advanced stuff that wasn’t directly supported by CRA (that happened multiple times) required me to understand the underlying config _and_ how CRA interfaces with it _and_ how to force CRA to generate the right configs. The classic leaky abstraction problem. Plus, CRA wasn’t bug-free leading to its own problems where I also had to dig into internals. That’s all significant maintenance burden too (added complexity). Out of the two options I’d almost certainly stick with “don’t eject”, but nowadays I heavily favour “don’t use these tools, keep build tooling simple”. And like so many people, I’m leaning more and more towards “it’s all so crazy complex (and broken) that it’s not worth it, don’t use React”. Things are getting _more_ complex with new developments rather than less, this is an insane ecosystem.
    - 2y ago
mattmanser 2y ago
When I switched from CRA/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. It's fairly trivial to switch too, though means you need to start understanding how webpack/vite/package.json/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. The only complication I could really see where the environment variable names, which we only used two anyway. By the way, I don't know why the author changed to using import 'components/blah' to '~/components/blah' as there's no real explanation in the blog post. The link for their commit is broken so can't see what the author has done. You actually don't need to do that, all you have to do is set 'baseUrl' in your tsconfig (e.g. "baseUrl": "./src"). That tells typescript where to look for imports. Then Rollup via Vite handles the rest in compilation.
- arbol 2y ago
  Webpack is much slower because it's written in JS. Vite uses esbuild to compile, which is written in Go. That's probably why you saw the speed up.
globalise83 2y ago
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).
art0rz 2y ago
We maintain a fairly large and complex CRA application, which has been migrated to Vite, but not fully. 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). Currently our production builds are done through CRA while dev runs Vite. It works really well and minimal code changes were needed. I've been wanting to release this config publicly to help others migrate to Vite, but have unfortunately not had time to.
- geekybiz 2y ago
  Sounds like an interesting approach. I'm sure a gradual approach like the one you mention would be super-helpful for anyone trying to migrate a complicated CRA app. I'm hoping you're able to find time to share in the near future.
racked 2y ago
Surprisingly painless, in my experience. Vite is good.
ricardobayes 2y ago
It's easier than people think, and it'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).
Noumenon72 2y ago
I was really happy to discover Vite so I don't have to change the way my whole app works with Next.js. Here are the differences I found from Create React App: * 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. * Running `vite` in IntelliJ with `npm run dev` will not show console logs in the IDE[1]. You don't need any of the solutions in that thread, though: just use a debug config. * You can add TypeScript types to your env vars with vite-env.d.ts. * Imports have to end in .tsx apparently: `import Foo from './components/Foo.tsx';` * No process.env: Since your code is running in the browser rather than on a Node.js server, there is no process env var. * 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't figure out how to suppress these messages. It won't happen in production since they still use a bundler in prod to save network round trips. 1: https://ww.reddit.com/r/react/comments/zo6nay/how_can_i_view_console_messages_in_terminal_when/ https://ww.reddit.com/r/react/comments/zo6nay/how_can_i_view...
- yurishimo 2y ago
  Regarding this point - Imports have to end in .tsx apparently: `import Foo from './components/Foo.tsx';` - since Vite uses ESM, each file that requires transpiling of some sort needs to contain a file extension so Vite knows to pass it off to some other service that converts it into plain JS before being sent to the browser. The same is/was true for `.vue` files as well. The webpack loaded had some config that would figure it out for you, but Vite requires that you import the component with the extension. Personally, I quite enjoy this change because now it's very explicit what file is being loaded and it opens up the possibility to load a JS file and some other file with the same name. Granted, small problem to solve, but in a huge project, it's not uncommon to see duplicate file names with different extensions sometimes.
- isleyaardvark 2y ago
  I'm pretty sure @vitejs/plugin-react allows you to leave off the file extension for imports. (I say this because I'm looking at a working Vite project with no file extensions, and that's one of the few differences with an out-of-the-box setup.)
rossng 2y ago
CRA seemed near-abandoned when I first tried it in 2020. I'm surprised to hear that people are still recommending it as the default. Vite works so well out of the box.
Aeolun 2y ago
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.
yurishimo 2y ago
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. 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'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. If anyone is running the old Laravel build pipeline, I suggest upgrading now because it'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.
- benchloftbrunch 2y ago
  > 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 I'd say that's more node's fault for half assing their ESM-CJS interop. Like, their solution to importing CJS was to go with a dumb static analysis thing. And their solution to requiring ESM was, you can't do it. Meanwhile bundlers had ESM and CJS working side by side almost flawlessly.
leros 2y ago
How is Vite compared to Next with static export? I moved my React apps over to Next earlier this year and I've been pretty happy.

60 points by luu 2y ago

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

tuyiown 2y ago
beware for large apps, if you don't have heavily splitted your app with dynamic imports, vitejs is frustratingly slow by loading each ESM module separately. Seems that rspac has others interesting tradeoffs. Works great once loaded though.
- iliaznk 2y ago
  We have encountered that problem too. As far as I learnt from various sources that is caused by circular imports in some cases, and by using index files that re-export your modules in other.
dangsux 2y ago
[dead]
- Vinnl 2y ago
  It hasn't been maintained for ages, so at some point you'll want to use some new dependency and find out that you can't. And it's very slow, too, if I recall correctly.
- chrysoprace 2y ago
  Not OP, but we had issues with SASS that made it difficult to upgrade. It didn't like the M1 architecture when trying to upgrade from Node 12 to Node 18, where as swapping it out for Vite just worked. Given CRA is deprecated, it made sense to move away. I followed a guide[0] which covered most of the things I needed to change and the remaining issues just involved following the build errors. We also saw much-improved build times, which was a welcome change. [0] https://cathalmacdonnacha.com/migrating-from-create-react-app-cra-to-vite https://cathalmacdonnacha.com/migrating-from-create-react-ap...

auggierose 2y ago

Both CRA and Vite seem to be a mess, I don't know how people work with that. My recommended stack: node, npm, typescript and esbuild.

mattmanser 2y ago
Vite is great, don't know why you'd make your own life hard like that.
- auggierose 2y ago
  On the contrary, this stack makes my life as comfortable as possible. I do understand esbuild, I don't understand whatever it is that Vite does.
  - lyxell 2y ago
    With Vite you do not have to hack together Hot Module Reloading yourself.
    - Aldipower 2y ago
      Thanks, so I won't use vite. Hot Module Realoading never worked reliable to me.
      - lyxell 2y ago
        I can’t speak for how it works in other frameworks but HMR for React works flawlessly in Vite.
      - conradfr 2y ago
        Because you did not use Vite.
      - homebrewer 2y ago
        CRA's HMR is a mess that breaks more often than it works, but I haven't had any problems with Vite's HMR after using it for the past three (I think?) years.

mkhalil 2y ago

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

nayroclade 2y ago
CRA seems pretty much abandoned. I wouldn’t recommend it for anything nowadays. There are much better options for both starter and serious apps.
JoeyJoJoJr 2y ago
I would never touch another project that has ejected from its build tool, and I am almost certain that I would never do an eject on my own projects. The maintenance burden is too high and it always becomes a complete mess as dependencies go out of date. I’d be interested to know for what reasons others have ejected? I have worked on 3 projects where some idiot dev had ejected for the silliest reasons. Since holding firm on my “never eject stance” I’ve never encountered a problem that I couldn’t solve without reading the docs more.
- williamdclt 2y ago
  I’ve been unhappy with both options. Ejecting gives you an incredibly complicated configuration (as CRA needs configs that can handle _any_ project) with a high maintenance cost as you say. Not ejecting gave me other headaches. Any advanced stuff that wasn’t directly supported by CRA (that happened multiple times) required me to understand the underlying config _and_ how CRA interfaces with it _and_ how to force CRA to generate the right configs. The classic leaky abstraction problem. Plus, CRA wasn’t bug-free leading to its own problems where I also had to dig into internals. That’s all significant maintenance burden too (added complexity). Out of the two options I’d almost certainly stick with “don’t eject”, but nowadays I heavily favour “don’t use these tools, keep build tooling simple”. And like so many people, I’m leaning more and more towards “it’s all so crazy complex (and broken) that it’s not worth it, don’t use React”. Things are getting _more_ complex with new developments rather than less, this is an insane ecosystem.
  - 2y ago

mattmanser 2y ago

When I switched from CRA/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. It's fairly trivial to switch too, though means you need to start understanding how webpack/vite/package.json/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. The only complication I could really see where the environment variable names, which we only used two anyway. By the way, I don't know why the author changed to using import 'components/blah' to '~/components/blah' as there's no real explanation in the blog post. The link for their commit is broken so can't see what the author has done. You actually don't need to do that, all you have to do is set 'baseUrl' in your tsconfig (e.g. "baseUrl": "./src"). That tells typescript where to look for imports. Then Rollup via Vite handles the rest in compilation.

arbol 2y ago
Webpack is much slower because it's written in JS. Vite uses esbuild to compile, which is written in Go. That's probably why you saw the speed up.

globalise83 2y ago

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).

art0rz 2y ago

We maintain a fairly large and complex CRA application, which has been migrated to Vite, but not fully. 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). Currently our production builds are done through CRA while dev runs Vite. It works really well and minimal code changes were needed. I've been wanting to release this config publicly to help others migrate to Vite, but have unfortunately not had time to.

geekybiz 2y ago
Sounds like an interesting approach. I'm sure a gradual approach like the one you mention would be super-helpful for anyone trying to migrate a complicated CRA app. I'm hoping you're able to find time to share in the near future.

racked 2y ago

Surprisingly painless, in my experience. Vite is good.

ricardobayes 2y ago

It's easier than people think, and it'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).

Noumenon72 2y ago

I was really happy to discover Vite so I don't have to change the way my whole app works with Next.js. Here are the differences I found from Create React App: * 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. * Running `vite` in IntelliJ with `npm run dev` will not show console logs in the IDE[1]. You don't need any of the solutions in that thread, though: just use a debug config. * You can add TypeScript types to your env vars with vite-env.d.ts. * Imports have to end in .tsx apparently: `import Foo from './components/Foo.tsx';` * No process.env: Since your code is running in the browser rather than on a Node.js server, there is no process env var. * 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't figure out how to suppress these messages. It won't happen in production since they still use a bundler in prod to save network round trips. 1: https://ww.reddit.com/r/react/comments/zo6nay/how_can_i_view_console_messages_in_terminal_when/ https://ww.reddit.com/r/react/comments/zo6nay/how_can_i_view...

yurishimo 2y ago
Regarding this point - Imports have to end in .tsx apparently: `import Foo from './components/Foo.tsx';` - since Vite uses ESM, each file that requires transpiling of some sort needs to contain a file extension so Vite knows to pass it off to some other service that converts it into plain JS before being sent to the browser. The same is/was true for `.vue` files as well. The webpack loaded had some config that would figure it out for you, but Vite requires that you import the component with the extension. Personally, I quite enjoy this change because now it's very explicit what file is being loaded and it opens up the possibility to load a JS file and some other file with the same name. Granted, small problem to solve, but in a huge project, it's not uncommon to see duplicate file names with different extensions sometimes.
isleyaardvark 2y ago
I'm pretty sure @vitejs/plugin-react allows you to leave off the file extension for imports. (I say this because I'm looking at a working Vite project with no file extensions, and that's one of the few differences with an out-of-the-box setup.)

rossng 2y ago

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

Aeolun 2y ago

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.

yurishimo 2y ago

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. 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'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. If anyone is running the old Laravel build pipeline, I suggest upgrading now because it'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.

benchloftbrunch 2y ago
> 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 I'd say that's more node's fault for half assing their ESM-CJS interop. Like, their solution to importing CJS was to go with a dumb static analysis thing. And their solution to requiring ESM was, you can't do it. Meanwhile bundlers had ESM and CJS working side by side almost flawlessly.

leros 2y ago

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