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
Related
I am learning React with my son using VS Code a and we are having a hard time properly syncing and setting up how to work with the same files on Github.
We have a repo with source files. Let's call it 1st-repo. His PC is fine as he has control of the repo (master). I would like to fork this repo (I think?) so I can have all the files and make my own changes.
I'm really not sure how to start in VS Code. DO I first do a blank app "npx create-react-app {name}" then clone? Or do I set it up through git/github in VS code.
Once there is the initial setup I would love to see how people work together.
You definitely don't want to npx create-react-app {name} as this will create a new application project.
If you are simply wanting to work on the same project at the same time then you only need to clone the Github repo to your machine.
git clone <link to repo>
Then change directory into the project and install the project's dependencies. This assumes you already have node installed on your machine.
cd <project directory>
npm install
From here you can open the project up in VSCode, make your changes, and commit & push them back to the remote repo. I suggest getting familiar with Git and the pull, commit, and push commands. Also get familiar with creating and switching between working branches.
Git cheet sheet
If you and your son are working on the same code in the same branch at the same time then merge conflicts will likely arise when either of you are pushing your changes back to the remote. Get in the habit of pulling any changes from the remote before you commit and push your changes, it's easier to resolve conflicts this way. VSCode even makes this stupid simple in the GUI.
VSCode also features a VS Code Share extension, called Live Share, that allows you to work in a shared window. You can see each other's cursors and position in the code.
Good Luck.
I'm wanting to create a React library that I can build locally and that deploys into the NPM global area. I want to be able to use my other React project that also sits on my machine and picks up changes as I modify the library. I have found plenty of tutorials that either deploy to NPM (which I don't want) or that I have no idea how to get it updating automatically to my project. I tried one with rollup.js that seemed to work for a while but then stopped for some reason.
Ideally looking for tutorial or source code that I can look at.
Do's: build locally, automatically update changes to my project
Don'ts: deploy to NPM or another external repository, cause problems when setup on another machine
Want: One library, one project, easy update to the project when the library is changed, be able to create an entry in the global install with the library version
Thanks
Paul
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
We've been a Windows shop, mainly relying on Visual Studio as our IDE and build tool. We've begun to explore using Angular and node, and angular-cli.
We have a project that depends upon "angular-cli": "1.0.0-beta.10". I was trying to get this to build on a new machine.
I installed nodejs, then did a global install of angular-cli using npm:
npm install -g angular-cli
Then I tried to do a build:
ng build
I got an error:
It seems like you're using a project generated using an old version of the Angular CLI.
The latest CLI now uses webpack and has a lot of improvements including a simpler
workflow, a faster build, and smaller bundles.
To get more info, including a step-by-step guide to upgrade the CLI, follow this link:
https://github.com/angular/angular-cli/wiki/Upgrading-from-Beta.10-to-Beta.14
What I did to get things working was to uninstall angular-cli, and then install version beta.10
npm uninstall -g angular-cli
npm install -g angular-cli#1.0.0-beta.10
After that, things work just fine.
Unfortunately, that's not a solution.
We will, eventually, have multiple projects using node packages, we need them to be able to run simultaneously, without having to uninstall and reinstall global packages.
And we need to be able to run builds automatically on our build machines, without having to RDP into the build machines to mess about with which node packages are installed.
That is, if I have three projects that use angular-cli#1.0.0-beta.10, I expect all three to work on any of the developers machines, and that the build machines will be able to check out any of the three projects and successfully build them.
And if I update one to use beta-12, and another to use beta-14, I expect to be able to commit them to version control, and for the build machine to be able to check out any of three and still be able to build them, regardless of which version they use.
I thought the whole idea of tracking local dependencies in package.json, and storing local copies in node_modules was to avoid dependencies on globally installed packages.
How do people usually manage this issue?
Is there a way I can configure angular-cli so it doesn't depend upon a global install?
Are there other packages with which I'm likely to encounter similar problems? Is there an approach that will work for any of them?
The Angular-CLI can be run with, and the global ng command uses, a locally installed version for each project. This local version can be accessed using the command ./node_modules/.bin/ng
I recommend uninstalling the global CLI you have and taking the time to modify your package.json scripts to reference the local CLI installation rather than the global ng. This is my method to handle varied CLIs on my Jenkins server.
On that note, I do highly suggest following the instructions to move from Beta.10 to Beta.14 (https://github.com/angular/angular-cli/wiki/Upgrading-from-Beta.10-to-Beta.14) if you can stomach the change to WebPack. Any projects utilizing CLI Beta.14 or higher can be upgraded to the latest beta simply by uninstalling the CLI, reinstalling it, and then running ng init (Diff [d] any files you've modified!) to update the boilerplate.
Copy & Paste the typescript components html's and css/scss files to a new build, it's not even worth it to mess with the core build of those stuff.
Bear in mind that you might see imports being grayed and the same very imports to be needed to add in app.module.ts as its a core file nowadays to every single project of ours.
I've installed another additional module for my app with bower. As project dependencies in bower.json were not very strict, and a lot of time passed since last update, bower updated a lot of packages to newer ones. There were a lot of changes, and incompatibility between packages was the reason for major app crash.
I never asked for this, not a good moment for total upgrade&debug. How can I just roll back to previous packages?
Original package sources are in .gitignore and built with grunt into one file (so I can't just revert the commit - as packages renewed by bower will be the same in the next build)
I couldn't find out the old package set which was OK for my app (as package sources with specific version numbers are in .gitignore) UPD: found versions in built file, see my answer
I couldn't find any information about sort of "bower package history" or "bower undo".
UPD: I solved the issue for myself and described the solution in the answer. But I'm really not sure it's a good way, and would be grateful for any kind of mentorship about the subject.
I solved the problem for myself by digging into incompatiblities showed by bower, and finding compromise package set. Main issues were between newest angular asked by some packages and angular-ui-bootsrap working with older versions only for that moment. Also there were some issues with other newest packages, which I downgraded and will solve later on. So I used bower install [PackageName]#=[SpecificPackageVersion] (can use --save here to save it to bower.json) for manually setting compromise packages.
At the moment I realized, that there were old package versions in license comment blocks in the previous commits of built file, so in order to have old working set of packages I could:
git checkout HEAD~1 to have old file, which was built with previous package set
grep (search) package names or license comments in it
bower install [PackageName]#=[OldWorkingPackageVersion] (can use --save to save it to bower.json)
git checkout [BranchName] to make HEAD back
Make build (with previous packages installed again)
However, I'm not sure it's a good solution, and would be grateful for any kind of clarification about the subject.