* 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...
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.
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.
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.
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.
Works great once loaded though.
We also saw much-improved build times, which was a welcome change.
[0] https://cathalmacdonnacha.com/migrating-from-create-react-ap...
My recommended stack: node, npm, typescript and esbuild.
CRA, yes. Vite, not in my experience. Vite does what it says it does, gets out of your way, is configurable enough when you need it to be, and has great testing tools. I don’t think I’ve ever had an issue with Vite.
esbuild index.js --bundle --outfile=build.cjs --format=cjs --platform=node
You can use pkg then to make this bundle executable.
pkg build.cjs
This is not vite. :-)
I do understand esbuild, I don't understand whatever it is that Vite does.
Edit: I don't know how Vite's HMR works, but it wouldn't surprise me if it is just piggybacking on esbuild's live reloading. Anyone here knows if there is a difference between the two?
My guess is that Vite relies on underlying tools as much as possible and only ejects when they need to. This is also why they are writing their own version of esbuild/rollup so that more of the dev pipeline can be controlled by Vite.
My code editor always auto saves changes so i just alt tab to browser and refresh to see changes
With live reload, often what happens, especially as projects get larger, is the watcher takes longer to trigger so the live reload is slower than just alt-tabbing, and it sometimes goes off on its own, probably due to multiple quick file changes, which is really annoying
I've never enjoyed this feature
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.
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.
What stack/tools are you currently using?
Maybe if it was something that first relied on a large framework, but CRA is not that. It is just a tool that kickstarts the development process, especially for the inexperienced.
Considering all it really provides is ESLint rules and a webpack config, if you're working on a serious project, a day or two of work shouldn't be a blocker. Besides, there are other options you can use besides webpack (e.g. vite, as in this post).
I know webpack scares many people, and TBH it is not a nice DX, but many enterprise/big projects require customizations that required ejections and a blanket statement like "I would never touch another project that has ejected" would severely limit your opportunities in working in the enterprise world.
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.