This project was bootstrapped with Create React App.
In the project directory, you can run:
npm start
Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.
The page will reload if you make edits.
You will also see any lint errors in the console.
npm test
Launches the test runner in the interactive watch mode.
See the section about running tests for more information.
npm run build
Builds the app for production to the build
folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Your app is ready to be deployed!
A netlify deployment link is automatically created for the latest commit on the master.
npm run lint
To see if there is standard style guide error.
To fix the errors run npm run lint-fix
npm run format
To see if there is style(format) error.
To format the styles run npm run format-fix
npm run format-lint-fix
To fix both format and lint errors.
Node 14.0.0 or later version
Some developers feel the need to debate code style. Other developers will use the project's style and get stuff done. We prefer developers who get stuff done. Consistency is important, please follow these guidelines.
We use the JavaScript Standard Style in our code. This is the style used by npm, GitHub, Zeit, MongoDB, Express, Electron, and many others. Be sure to use an automatic formatter like standard-formatter for Atom and vscode-standardjs for Visual Studio Code.
Line length should be limited to 80 characters.
package.json
, e.g. require('http')
require('./api')
module.exports
module.exports
should be as close to the beginning of the file as possible. The module should export either a single function or a "catalog object", e.g. module.exports = { method1, method2, ... }
route()
or verb combined with a noun like routeRequest()
.Version control is a project's best source of documentation when done correctly. When trying to understand code it's extremely useful to use git blame
to find both the PR and the issue associated with that change.
PRs should be small and focused. Each commit should solve a single problem and be covered by a test that exemplifies that particular feature or fix.
All PRs must be reviewed by a teammate before they are eligle to be merged into the master
branch. Large PRs are difficult to review. Be sure to break large PRs into smaller ones so that they can be reviewed quickly and deployed to production.
chore:
, docs:
, style:
, refactor:
, perf:
, and test:
.gitignore
to add files related to your editor or environment. Use your own global .gitignore for that instead.We use Zenhub to manage our workflow. Each task is represented by an issue. Be sure to connect any PR you are working on to the appropriate issue. Do this via the Zenhub interface and by adding Closes #X
where X
is the issue number to the PR description in Github.
As tasks move from Backlog to In Progress to Needs Review to Needs QA to Ready to Deploy and finally to Closed.
We have a dedicated Slack channel for posting PRs: #nand2tetris-prs. Every PR should be posted in this channel, allowing for others to know that you have work that needs review. Communicating updates about the PR will happen in a thread attached to the original Slack message for the PR.
The process for posting a PR in Slack is:
@<developer_who_made_PR> reviewing
pushing back to In Progress @<developer_who_made_PR>
.@<developer_who_made_the_comment> all comments have been addressed. Pushing back to Needs Review
@<developer_who_made_PR> approved
Please note that all discussion about the PR should stay in GitHub. Threads are not intended a place to discuss the code itself. Slack is only used to provide more immediate feedback.
Commit types (e.g. feat
, fix
, refactor
, style
) are important because they are a signal to the reviewer for what they should be looking for and how much scrutiny the review needs. Reference from Angular:
Feature commits require the most scrutiny. They add or change functionality, require additional tests, and have the greatest chance of introducing a bug.
Fix commits are smaller and have a more bounded scope than feature commits. Features usually introduce multiple new behaviors, but fix commits will only modify a single behavior. Fix commits need to provide additional test coverage because the existing tests were insufficient to catch the error. Feature commits should have multiple tests for these behaviors, but fix commits typically introduce a single test to prove that the error has been fixed (test should fail without the fix inactive and pass with it active). These commits can introduce additional bugs, but it’s less common than feature commits.
Refactors need less scrutiny than feature or fix commits because little about the app changes. All consumers of the refactored part of the app should be 100% unaware of the change. If module A is refactored, and module B depends on A, module B does not need to be tested because A hasn’t changed anything from their perspective. Similarly, anything that depends on B doesn’t need to be tested either, no change should bubble up to cause issues. Since nothing is changing, any existing tests/QA should already be sufficient to catch any issues created by the refactor. Refactors don’t generate additional tests.
Style commits need the least amount of scrutiny. They tend to be very repetive (converting from snake_case to camelCase, standardizing indentation, or changing newlines). These changes will have no functional impact on the code and any existing tests should be sufficient.
All communication about projects should be in #nand2tetris. Do not use direct messages unless you are discussing something private. It is important that all conversations and questions (no matter how small they seem) should be in #nand2tetris. We work as a team and that requires sharing, being transparent, and allowing the whole team to have a chance to answer your questions and to learn from the dialogue.