The central repository for the Chameleon front_end_project (react.js) and back_end_project (node.js) .
To get started, clone the repo. Then run npm install from the root.
The repo is organized as a monorepo, . and follows this structure:
├── back_end_project # All API to be created here (node.js)
├── controllers
├── routes
└── services
├── front_end_project # Customer facing website (React.js)
├── public
└── src
├── components
├── layouts
├── pages
├── services
└── old_website # Old Chameleon website code
Both back_end_project and front_end_project are workspaces. Most actions, such as installing new npm packages, can and should be performed at the respective folder and not in the root of the project. Specific workspaces can be targeted from the root directory using cd <workspace>.
e.g. To install a new package to the front_end_project package only cd front_end_project then npm install package-name
Note: Running npm add <package> will install it to the root . T.
From the root, run npm run devall to launch both node server and react app.
From the root, run npm run server to launch node server alone. This can be used by API developers to test their api , through POSTMAN.
Development should follow the Feature branch git workflow
Never commit directly to
main
👉 Note::
When pulling the latest from github, you may need to run
npm installif any packages were added or removed in past commits. If you are experiencing errors unrelated to the code you are writing (or before writing any), try runningnpm install.
Code quality is enforced by ES Lint which is configured as an custom eslint plugin shared across the entire project in eslintrc.js.
Each package/app requires their own .eslintrc.js file.
- Components, Component directories, Component files, and Stories all use
PascalCase / UpperCamelCase - Variables and functions use
camelCase - Single quotes for strings
- Do not use string interpolation for css classes
- Do not use CSS-in-JS, StyledComponents or Emotion CSS
Branches are used for isolated feature development and should always branch from the source they intend to merge into. This means that a branch created from main must always end up in main.
Using the example branches of main-> feature-1 -> feature-2...
- ❌ do not merge
feature-1intomainbeforefeature-2is merged. - ❌ do not merge
feature-2directly intomain, only its parent branch. - ✅ do branch
feature-2frommainsince it should not depend onfeature-1
NOTE if it's entirely necessary to merge
feature-1beforefeature-2, ensure that no manual commits are made infeature-2between the last commit & merge commit tomainoffeature-1.
There are no hard constraints imposed on commit messaging, instead the following guidelines show a best-practice approach to producing consumable commit messaging.
The preferred format for a commit message looks like this. Note that only body is required:
# format...
"type?(scope?): body..."
# examples...
"fixed some issue"
"fix: fixed some issue"
"fix(US-123): fixed some issue"
"fix(component): fixed some issue"typerefers to what kind of commit is being made. Some example values are:
[
'build', // related to build processes
'chore', // small cleanup activities or other pedantry
'ci', // related to continuous integration activities
'docs', // documentation work
'feat', // feature work
'fix', // bugfixes or hotfixes
'perf', // performance tuning & optimization
'refactor', // code refactoring
'revert', // reverting previously committed changes.
'style', // styling changes
'test', // changes to tests
];scopeprovides context to the commit type, most commonly a TRELLO ticket or some project name.body...refers to the bulk of the commit message, which can break up into header and footer sections delimited by newlines.- A header is the body section on the first line of the commit message
- A footer is entered a full newline separated from the header and may contain any length of UTF-8 content.
React Bootstrap - Docs
To see all licenses for the project run npx license-checker --summary
or see license-checker docs for more options