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.
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 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'm creating a JS web app, and I know there are a lot of commands I use to set up my project: git init, npm init, etc. However, I also want to do two other things that sort of set up a barebones project for me: create-react-app and truffle init.
What exactly do each of these commands do, and what is the correct order I should run them in (truffle init I believe just creates some folders)?
I am mostly wondering if multiple package.json files are bad, or node_modules folders, or git files, since create-react-app seems to do some of things git init and npm init do. For one, I know create-react-app initiates a git repo. But I would like to put all react stuff in a "client" folder, and there are other things in the root of the directory. Is it bad to have nested git repos?
The short answer is: no, you shouldn't have multiple git files and node_modules folders and so on in your project (unless it's on purpose), simply because it makes it unclear which one your project should use.
git init creates a new git repository. You don't need to do this when using create-react-app and truffle init, because they already do it for you.
create-react-app creates a boilerplate for your project, and truffle is another boilerplate, so those shouldn't be used together. Pick one and stick with it.
When it comes to multiple git repos, there are different ways to do this depending on what you want. I suggest reading up on submodules, which is the intended way to have repos inside other repos. An alternative is to use a monorepo, which means using a single repo for multiple parts of the project, for example client and backend.
Apologies, I am still a bit confused by git, although I am trying to teach myself more and improve.
I recently successfully deployed a React website to GitHub pages, following the often recommended steps of installing gh-pages to the project, adding a homepage property to the package.json file, adding scripts to the scripts properties on the package.json file, running 'npm run deploy' and so on. It worked fine, and now a build of the project has been added to my repository (here), and I can view the actual project online (here).
However, the issue I have is this: most guides on deploying a react app also mention the following steps:
in the terminal type:
git add .
git commit -m "commit"
git push origin master
These final steps are often listed as optional. Everything worked fine without me doing these steps: my code was added to the repository, and my website is deployed online, so what do these steps do exactly? Why are they considered optional? What is best practice?
These commands are not optional to me - when using only the command-line Git client, these commands accomplish the interaction of pushing the code (that, after you edit it, only exists locally on your own PC) to the Git repository server.
Everything worked fine without me doing these steps: my code was added to the repository, and my website is deployed online
I can see the following possibilities:
You are using another Git client and the push was done there;
You are using a Git tool (e.g. editing purely on the GitHub website), where the push happened without you being aware of it;
You did the terminal commands, without being aware of them;
A common resource to learn more about Git would be the Git book on the official Git SCM website: https://git-scm.com/book/en/v2
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