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.
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/
Primarily, I'm trying to integrate a react application (Created and build separately) with Drupal.
Problem
Unable to install private package from Bitbucket using npm install git#bitbucket.org:user/shared-package.git in Drupal app, because no package.json found.
Implementation Details
Development Environment
To achieve this in development environment I run npm run build which produces the following content in dist directory.
Not going in the details of what are the roles of other files but to make the things work, I just need to copy bundle.js file and paste it inside a directory under app/web/themes/custom/abc_themes/js/.
This is okay for development environment to copy a folder from one project and paste it into another. However, for production environment it' not viable.
Production Environment
In production we thought to create a private package on Bitbucket, where through Bitbucket pipelines on every commit we trigger a build and push that build 's result into a separate repo (i.e. private package).
Here is the content that is pushed to the so-called private package. Since it's the entire react application (not a library) therefore when it builds it creates compiled js and doesn't contain packgae.json.
Now if I try to install this package throught npm install
code ENOLOCAL
npm ERR! Could not install from "bitbucket.org:user/shared-package.git" as it does not contain a package.json file.
That is obvious but to solve this I can't convert my project into a library. Because even if I convert it to a library, Drupal needs a build js file at the specified directory to work.
Expectation
Want to know if there is a way I could install that private package (that doesn't have package.json) into Drupal application.
OR any other way around to achieve the same.
NOTE: I know one solution could be to host the build file at some CDN and pull it from there. But problem is, the Drupal app might be running behind a corporate network and users won't be able to access the internet openly. Therefore, we want to make the react app a part of build process, so once Drupal is served, react application would be a part of it already. No loading at runtime.
i have an existing project folder that contains project assets, some text files, &c. and we're having to use React on this one. when i run create-react-app . or npx create-react-app <folder>, it errors out saying i have to remove existing files because 'they might conflict'. SMH. how do i override this behaviour and force it to deploy? because i'm not doing this for every project we do...
and, no, this post has nothing useful to offer.
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 have been trying out Codeship and Heroku for continuous deployment of an AngularJS application I writing at the moment. The app was created using Yeoman and uses bower and grunt. Initially I thought this seemed like a really good setup as Codeship was free to use and I was quickly able to configure this to build my AngularJS project and it offered the ability to add a deployment step after the build. There were even many PaaS providers to choose from (Heroku, S3, Google App Engine etc). However I seem to have become a bit stuck with getting the app to run on Heroku.
The problem started from the fact that all the documentation suggested that I remove the /dist path from my .gitignore so that this directory is published to Heroku post build. This was mainly from documentation that talked about publishing to Heroku from a local machine, but I figure this is all Codeship is doing under the hood anyway. I didn't want to do this as I don't believe I should be checking build output into source control. The /dist folder was added to .gitignore for a good reason. Furthermore, this kind of defeats the point of having a CI server somewhat, as I might as well just push the latest build from my machine.
After some more digging around I found out that I could add a postinstall step to my packages.json file such as bower install && grunt build which would re-run the build on Heroku and hence repopulate all the bower dependencies (something else they wanted me to check in to source control!) and the dist directory.
After giving this a try it became apparent that I would need to add bower and grunt as dependencies in packages.json, which meant moving them from devDependencies which is where they should belong!
So I now seem to be stuck. All I want to do is publish my build artefacts (/dist) the dependencies (/bower_components) and the server.js file that will run the site. Does anyone know how to achieve this with Heroku and Codeship? Alternatively has anyone had any success with this using different tools. I am looking for something that is free and I am willing to accept that it will not be production stable (won't scale to multiple servers etc), but this is fine for now as all I want to do is continuously deploy the app for internal testing and to be able to share the output with non-technical members of my team so we can discuss features we'd like to prioritise etc.
Any advice would be greatly appreciated.
Thanks
Ahoy, Marko from the Codeship crew here. Did you already send us an in app message about this? I'm sure we can get your application building on Codeship and deploying to Heroku successfully.
As a very short answer, the easiest way to get this running would be to add both bower and grunt to your dependencies in the package.json. Another possibility would be to look for a custom buildpack with both tools already installed.
And finally you could also run the tools on Codeship, add the newly installed files to the repository, commit the changes and push this new commit to Heroku. If you want to use this, you'd very probably need to force push the changes though.
Feel free to reach out to me via the in app messenger (lower right corner of the site) and I'd be happy to help you get this working!
I found two ways to get this to work.
Heroku Node Custom Buildpack
Use the mbuchetics Heroku build pack. This works by basically re-building the app once it has been pushed to Heroku.
There were a few tricks I had to employ still to make this work. In Gruntfile.jstwo new tasks needed to be configured called heroku:production and heroku:development. This is what the buildpack executes to build the app. I initially just aliased the main build task, but found that the either the buildpack or Heroku had a problem with running jshint so in the end I copied the build task and took out the parts that I didn't need.
Also in packages.json I had to add this:
"scripts": {
"postinstall": "bower cache clean && bower install"
}
This made sure the bower_components were available in Heroku.
Pros
This allowed me to keep the .gitignore file in tact so that the 'binaries' in the dist directory and the dependencies in the bower_components directory were not committed into source control.
Cons
This is basically re-building the app once it is on Heroku and I generally prefer to use the same 'binaries' throughout the entire build and deployment pipeline. That way I know that the same code that was built, is the same code that was tested and is the same code that was deployed.
It also slows down the deployment as you have to wait for the app to build twice.
CodeShip Custom Script Deployment
Not being satisfied with the fact I was building my app twice, I tried using a Custom Script pipeline in CodeShip instead of the pre-existing Heroku one. The script basically modified the .gitignore file to allow the dist folder to be committed and then pushed to the Heroku remote (which leaves the code on the origin remote unaffected by the change).
I ended up with the following bash script:
#!/bin/bash
gitRemoteName="heroku_$APP_NAME"
gitRemoteUrl="git#heroku.com:$APP_NAME.git"
# Configure git remote
git config --global user.email "you-email#example.com"
git config --global user.name "Build"
git remote add $gitRemoteName $gitRemoteUrl
# Allow dist to be pushed to heroku remote repo
echo '!dist' >> .gitignore
# Also make sure any other exclusions dont apply to that directory
echo '!dist/*' >> .gitignore
# Commit build output
git add -A .
herokuCommitMessage="Build $CI_BUILD_NUMBER for branch $CI_BRANCH. Commited by $CI_COMMITTER_NAME. Commit hash $CI_COMMIT_ID"
echo $herokuCommitMessage
git commit -m "$herokuCommitMessage"
# Must merge the last build in Heroku remote, but always chose new files in merge
git fetch $gitRemoteName
git merge "$gitRemoteName/master" -X ours -m "Merge last build and overwrite with new build"
# Branch is in detached mode so must reference the commit hash to push
git push $gitRemoteName $(git rev-parse HEAD):refs/heads/master
Pros
This only require a single build of the app and deploys the same binaries that were tested during the test phase.
Cons
I've used this script quite a few times now and it seems relatively stable. However one issue I know of is that when a new pipeline is created there will be no code on the master branch so this script fails when it tries to do the merge from the heroku remote. At the moment I get around this by doing an initial push of the master branch to Heroku before kicking off a build, but I imagine there is probably a better Git command I could run along the lines of; 'only merge this branch if it already exists'.