I came into a team that had already started a React team. The installation takes 30 minute into the cloud because of all the dependencies in node_module. When I look in this folder, there are 1084 folders. I'm pretty sure there are a lot of stuff here that is never touched, but may also be in the package.json. In attempted to clean up and speed up the installation process, is there any automated way to find out if our project actually needs it, without removing one item at a time?
1) https://github.com/depcheck/depcheck to clean you package.json
2) delete node_modules and reinstall everything
Related
I've recently tried getting into the whole Node ecosystem and am trying to set up some continuous deployment for my app to AWS Amplify.
For background, my project structure looks like this:
project
public
index.html
src
App.tsx/App.js
package.json
As far as I know, this is basically what create-react-app gave me to start with, and I didn't change the file structure.
For most of my time working on the app, I've been able to go to the base project directory and use
npm start
to launch the app. This will bring me to the App.tsx/js homepage.
However, when I hosted this to AWS Amplify via GitHub, the default build settings actually point to the public directory, so the published site is actually point to index.html (which is basically just an empty placeholder).
While debugging, I ran
npm build
in my root project directory, which constructed a build folder, so now the overall project looks like this:
project
build
index.html
public
index.html
src
App.tsx/App.js
package.json
Now, running
npm start
will bring me to the index.html from the build directory, instead of App.js/tsx as it used to.
The AWS setup says that it will run
npm build
so I assume that what I've done on my local machine is mirroring what the AWS server is doing behind the scenes and explains why AWS is serving the empty index.html.
I've read a few articles and watched some videos about hosting a create-react-app on AWS, and in every version, it looks like AWS will serve the App.tsx/App.js right out of the box, rather than build/index.html, and I've not been able to find a good guide on how to configure this behavior. Quite frankly, there is an overwhelming number of similar-but-slightly-different answers for questions like this, which use different combinations of package managers, packages, hosting services, all on different release versions, with different setups, and it's very difficult for me to tell which ones apply to my scenario.
So I'm hoping someone can help straighten some of this out for me, or point me towards a good resource for learning more about this type of thing. Particularly interested in learning the right way to do these things, rather than a quick hack around whatever my particular issue is.
Some specific questions...
Is deploying things from a /build folder standard convention?
Why does create-react-app create a separate /src/app.tsx and /public/index.html that seem to be competing with one another as the app's "homepage"?
Why does the behavior of
npm start
change depending on whether
npm build
has been run?
Is the correct fix here to just insert my App.tsx component into the index.html? This doesn't seem hard, but doesn't seem right either
I have seen a lot of answers discussing tweaks to webpack.config.js to solve issues like this one. My project does have webpack installed, but as best I can tell, there is no webpack.config.js anywhere. Am I expected to create this file, or should it exist already? In either case, in which directory is it supposed to live? I've seen a couple answers saying it should be in /node_modules/webpack/, but also some saying it needs to live in the same directory as package.json
Things I've tried already: Spent a bunch of time reading through other StackOverflows and watching a few videos, but as outlined above, I'm finding it difficult to tell which could apply to my situation and which are unrelated, given the huge number of unique combinations of build/packages/platforms/versions. Also spent some time monkeying around with file structure/moving code around, but not very productively.
Eventually found my issue. In the production built version of my app (aka, /build), the bundled script created by webpack was failing in the browser because exports was undefined, so index.html was being served in its vanilla state, rather than with the TSX/JSX content. I changed the "module" property in tsconfig.json from commonjs to es6 and this fixed most of the problems.
Also of note is that the reason I couldn't find my webpack.config.js is that I had hidden ALL js files in my project, so VSCode wasn't finding it. I swapped to the suggestion from this blogpost to hide only js files with a matching TS file.
For general learning about how create-react-app works, I eventually found this page, which I found helpful:
https://blog.logrocket.com/getting-started-with-create-react-app-d93147444a27/
For the basic create-react-app
npm start
Is a short command for react-scripts start that sets up the development environment and starts your development server usually localhost:3000
npm build
After you are done developing, this command short for react-scripts build correctly bundles your app for production and optimizes the build for the best performance.
The files generated in the build folder are solely the files you serve to the public folder accessible by the public URL.
In short the files in the build folder should be copied to the public folder
AWS Amplify
Provides a CI/CD process where you don't have to set all this up by yourself, as long as you have a well-configured package.json file.
There are so many methods to deploy your react app to a production server but using AWS Amplify this link might help you out: https://youtu.be/kKwyKQ8Jxd8
More on create-react-app deployment: https://create-react-app.dev/docs/deployment/
I'm working on an old react project, which I need to add functionality to, but when deploying the react build on the server, it fails, claiming it cannot find several css and js files, although I published all files within the build folder. I tried different things:
First, I kept the old service-worker.js in the production folder the IIS uses, but replaced everything else.
Then, I tried also deleting the service-worker.js, since I thought it was optional, and my npm run build didn't create a service-worker.js file.
Then, I tried copying the service-worker.js file that existed on production, and manually changing it to point to my css and js files in the /static/ folder of my build folder.
All of these solutions have yielded the same result. So I have a few questions:
Is the service worker necessary? If not, could this error relate to something entirely different other than the service worker?
If it is necessary, why could my npm run build command not create the service worker with the rest of the files in the build folder?
If I do need it, how can I manually add it to a project that already exists?
If the production folder already had a service worker, and my build is not building it, I can also assume maybe my react version is newer, but I find that odd, since the computer I use is one an older employee in my company used, and I didn't manually change anything about this project.
I'm working on a project built by someone else. I know it was bootstrapped by create-react-app because it says so in README.md.
However, I'm not sure if it has been ejected or not. There are many posts out there teaching you how to actually eject it, but I failed to find a way to check it in the first place. Any help is appreciated!
Some immediate giveaways that a create-react-app project has been ejected:
The dependencies field in package.json no longer contains react-scripts. Instead, it is populated with many additional packages like Babel, Eslint, Jess, Webpack and various Webpack loaders.
The absence of eject script.
The start, build and test no longer follows this format react-scripts start, react-scripts build etc.
A new directory named config appears.
Just sharing because you may or may not see all of these signs in your project as they were probably ejected a long time ago. I hope no one will spend two hours wondering why a certain package didn't work only to discover that the project has been ejected and the package only works with unejected ones.
Many thanks to #YuryTarabanko!
So I tried creating another project using CRA and ejecting it. Right after the ejection, a new directory called config popped up and there were some modifications in other directories, too.
Then I took a look at the project I'm actually interested in. The config directory is right there, with a structure similar to that config dir in the new project that popped up after the ejection. So I'm sure this project has been ejected, too!
Edit:
As Yuri pointed out in the comment:
The most noticeable difference IMHO would be the absence of eject command in package.json#scripts section though ;)
I somewhat agree with the script in package.json, but it could have easily been removed. If the project is in a repo, you should be able to look at the history of a few files to be certain.
It's my first experience with react and as stated in official docs, I was trying out create-react-app to create my first react app.
But I notice that it takes around 15-20 minutes to get finished( even though I have good internet connection) and once it was completed, I noticed the space taken by the newly created folder to be around 165-170 MB.
Isn't there any quicker way to get started with react as the above mentioned method probably installs some modules that are never going to be used.
Thank You.
I also faced the same problem when i first started learning react. What i did was i manually configured webpack to bundle my code. And then i created central node_modules folder in particular place. So anytime i want start a react project i just create a symlink to the node_modules folder. And also if i want install a new package, i go the central folder and install it, so the package will be available in the node_modules folder and for any of my project that may need it. That way i only need to install a package once not every time i want to use it for a new project.
But recently i found a package manager called pnpm. Instead of downloading a package anytime need to install it, pnpm maintains a central cache of packages such that anytime you want to install a package, it just creates a symlink(or junction in windows) (similar to what i used to do).
Conclusion
In conclusion i would recommend you to just configure a bundler (vite is cool) by yourself and use pnpm to install packages. You can read more about pnpm on there website
I'm using angular-ui-calendar which is at 0.8.0 in bower. I see a problem, and I see it has been fixed on the master branch, but there is no new release. In fact there are quite a few changes between 0.8.0 and the HEAD of the master branch.
I can copy their latest master into my bower_components folder, BUT that won't help anyone else (including jenkins) because when bower_install is done on any other machine, it won't get my changes.
Is there some viable method to deal with this kind of problem that already works?
Do I setup my own bower repos and publish my own version of 0.8.1 for my company?
Do I setup a script that will apply my fixes to the bower_components folder?
Do I add bower_components to git and then check them out the same way I get the rest of my project?
I'm seriously leaning toward the last method because that removes the need for bower to install in other places (bower is struggling to get those 5 9s of reliability)
What problems could ensue if I commit bower_components to my own repo?
(I have a similar problem with ng-grid, so it isn't just the calendar that is giving me heartburn)
I finally decided to commit my bower_components to the git repo so that if I need to make changes to something between releases, I can do that. So far, so good. It also helps me remember when I need to add things to the bower.json file (with --save or manually) since those things are now tracked by git, they show up as untracked files.
Also allows me to diff the changes to components, if I update my bower packages, I can see what changed in those packages and how that might affect my project.