We have an application that has multiple packages linked using yarn link.
When developing our app, we run ‘yarn start’ at the root which runs react-scripts and fires up the local server which is webpack under the hood from CRA.
We then run yarn start on the package we are updating, this runs a watch using webpack.
When we make a change in a package, the change is detected and react-scripts server hot reload recompiles, but it takes almost 20 seconds for the compilation to complete and a few more seconds for the browser to then reload to reflect the changes made.
I recently updated our versions of react and react-scripts to the latest and it seems to take even longer than the previous versions so it’s now taking about 30 seconds to reload.
I was wondering if it’s because we aren’t using yarn workspaces or a monorepo in general.
Does anyone have any experience with this and know of anything to speed things up as it’s becoming painstaking to work on our application as it currently is.
We tried to migrate to vite, but our application is too big to overhaul.
We heard snowpack might help but not sure how to migrate to that.
Does anyone know of any other potential tweaks like doing something to source maps or any drop in replacement for webpack that can help, that works with linked packages?
Thanks
Related
I have been working with reactjs from last 7-8 months, I have always used create-react-app to get started with any react application. but, by exploring more ways to get started with a react application I came to know there is a thing called vite which is I guess is providing a faster and leaner development experience for modern web projects.
I used it once till now, not in production yet as I am not very confident about it. So, which is a better way to get a simple template for react app. which is also better in production environment. Does using any one affects in production?
CRA uses webpack to handle its core functionalities. In the development webpack repeats the bundling process every time there is a change in the code. As a result, when your source code grows larger, everything becomes sluggish. The time it takes to serve a dev server and build your projects increases significantly.
Vite only needs to pre-bundle your dependencies using esbuild the first time you start development before it begins to serve your app.
Vite doesn’t need to bundle the entire app or transpile the modules and code before starting a dev server; transpiling is done on-demand, thus making it significantly faster than CRA.
https://blog.logrocket.com/vite-3-vs-create-react-app-comparison-migration-guide/#:~:text=Vite%20and%20CRA%20are%20not,and%20which%20modules%20are%20supported.
I have just created a regular create-react-app application, with the aim of sketching out components for a future project. But I ran into the problem that in order to see at least some, even small, changes purely in the text of the rendering component, you need to completely reboot the server using npm start.
And so with everything. I can even delete all the files from the root folder where I installed create-react-app, and the site on 127.0.0.1:3000 will still work (I tried). What should I do to enable hot-reloading?
I am using create-react-app to create my react projects boilerplates but recently launching my projects with npm start is too slow and most recently hot reloading is slow take from 5 - 15 secs to rebuild the page after any change especially when rebuilding after an error.
I really don't know much about webpack, after some search i found that problem can be from webpack or webpack-dev-server but i don't know much about them
so i don't know from where should i move to solve this issue?
If you're developing a React project in a Windows Subsystem for Linux 2 (WSL2) environment, it's especially important that you work within the WSL2 directory structure for optimal I/O. For example, you'll want to put the project in "~/repos/my-project", not "/mnt/c/Users/my-username/repos/my-project". They aren't the same location. You can confirm this by running "explorer.exe ." from the terminal.
I'm completely asea here.
We had a working app build with an old Electron Forge (^5.2.4; 5.2.6) created using the old React template (1.0.2-1.0.4) with the usual suspects of React tech (react-redux, react-router, etc.)
Up until about 1-2 weeks ago everything has been fine. Now, after running its startup code, showing some components, doing some things, then we get a Variant 119 error (ref issues or multiple versions of React).
Since the code used to work the ref thing seems spurious, but I checked all our refs (there are a total of two). I did the usual npm ls and yarn list, even checked a lot of modules for additional Reacts, but found nada.
Our yarn.lock file has not changed other than some internal dependencies that aren't Electron or React related. No external components (BlueprintJS, Semantic UI React, ...) have changed over the course of working-to-non-working.
Here's the kicker: reverting to previously-working versions (including deleting node_modules etc.) doesn't help. The build machine is running the same version of NodeJS as it has been (10.15.mumble). I've tried to track down caches (including Yarn) and deleted them, deleted the out directory, done full rebuilds, etc.
What could be impacting an Electron Forge build like this? What other code, directories, caches, configurations, etc. should I be looking for?
That it impacts previously-working versions points me towards build/environment problems, although this happens across machines, which points back at the project. After multiple days bisecting and rebuilding and having the same thing happen I've paid a visit to Witt's End. And I don't like it there.
Looking at the error message, it lists two different reasons for the error. It seems you have ruled out multiple react instances in your code, but be wary if you use npm link as that can do weird things with dependencies.
So have you check to see if someone on your project team checked in something that is trying to use a ref where they shouldn’t as that will also cause this error
my current front-end dev setup is below:
browserify as build tool
budo as a development server
I have a couple of shared modules packaged up and published on npm for use as a dependency among many projects.
However the development feedback cycle is too long since I have to run npm link ../<repo> && npm run dev every time I need to see an updated change and it takes too long to finish linking , approx. 2-5 minutes.
Is there a way I can watch changes in my link'd module and it will rebuild files that were changes?
Budo (browserify) should follow symlinks, so once you npm link then you should be able to edit both modules concurrently (and get live reload) without having to re-run any commands. This is assuming your other module doesn't need a transpile step. If it isn't working, perhaps it's a bug or some other issue. Feel free to open an issue on budo's GH issues to discuss further.
– #mattdesl