Run npm i
to install the dependencies.
It will also create the Git hooks with Husky if you Git version is recent enough.
Run npm run start
to start the local development server.
This project was generated using Nx.
🔎 Nx is a set of Extensible Dev Tools for Monorepos.
10-minute video showing all Nx features
Nx supports many plugins which add capabilities for developing different types of applications and different tools.
These capabilities include generating applications, libraries, etc as well as the devtools to test, and build projects as well.
Below are our core plugins:
- Angular
ng add @nrwl/angular
- React
ng add @nrwl/react
- Web (no framework frontends)
ng add @nrwl/web
- Nest
ng add @nrwl/nest
- Express
ng add @nrwl/express
- Node
ng add @nrwl/node
There are also many community plugins you could add.
Run ng g @nrwl/angular:app my-app
to generate an application.
You can use any of the plugins above to generate applications as well.
When using Nx, you can create multiple applications and libraries in the same workspace.
Run ng g @nrwl/angular:lib my-lib
to generate a library.
You can also use any of the plugins above to generate libraries as well.
Libraries are shareable across libraries and applications. They can be imported from @yokai/mylib
.
Run ng serve my-app
for a dev server. Navigate to http://localhost:4200/. The app will automatically reload if you change any of the source files.
Run ng g component my-component --project=my-app
to generate a new component.
Run ng build my-app
to build the project. The build artifacts will be stored in the dist/
directory. Use the --prod
flag for a production build.
Run ng test my-app
to execute the unit tests via Jest.
Run nx affected:test
to execute the unit tests affected by a change.
Run ng e2e my-app
to execute the end-to-end tests via Cypress.
Run nx affected:e2e
to execute the end-to-end tests affected by a change.
Run nx dep-graph
to see a diagram of the dependencies of your projects.
Visit the Nx Documentation to learn more.
Nx Cloud pairs with Nx in order to enable you to build and test code more rapidly, by up to 10 times. Even teams that are new to Nx can connect to Nx Cloud and start saving time instantly.
Teams using Nx gain the advantage of building full-stack applications with their preferred framework alongside Nx’s advanced code generation and project dependency graph, plus a unified experience for both frontend and backend developers.
Visit Nx Cloud to learn more.
This project uses an alias to push automatically with the upstream option set.
The configuration of the alias is a local one.
This alias is used by the cz
script to automatically push on the remote with a dynamic branch name.
Troubleshooting:
If the command push-upstream
does not exists, you can link it to your git:
Run git config --local include.path ../.gitconfig
.
Note:
The error should be something like:
git: 'push-upstream' is not a git command. See 'git --help'.
We have very precise rules over how our git commit messages can be formatted.
This leads to more readable messages that are easy to follow when looking through the project history.
Each commit message consists of a header, a body and a footer.
The header has a special
format that includes a type, a scope and a subject:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The type and the subject are mandatory.
All the other stuff is optional.
Any line of the commit message cannot be longer 144 characters!
This allows the message to be easier to read on GitHub as well as in various git tools.
If the commit reverts a previous commit, it should begin with revert:
, followed by the header of the reverted commit.
In the body it should say: This reverts commit <hash>.
, where the hash is the SHA of the commit being reverted.
Must be one of the following:
- feat : A new feature
- fix : A bug fix
- style : Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf : A code change that improves performance
- test : Adding missing tests or correcting existing tests
- build : Changes that affect the build system, CI configuration or external dependencies
- docs : Changes that affect the documentation
- chore : Anything else
The scope could be anything specifying place of the commit change.
For example datepicker
, dialog
, app
, etc.
The subject contains succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize first letter
- no dot (.) at the end
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes".
The body should include the motivation for the change and contrast this with previous behavior.
The footer should contain any information about Breaking Changes.
Breaking Changes should start with the word BREAKING CHANGE:
with a space or two newlines.
The rest of the commit message is then used for this.
In some cases (probably due to a lack of ingenuity so any help is wanted) during the development some features are linked.
To help linking seem together we use comments to identify those cases.
To identify them easily the following syntax is used:
@see [sonia-link-XXX]{@link https://github.com/Sonia-corporation/yokai/blob/master/CONTRIBUTING.md#sonia-link-XXX}
where XXX
is an id.
Here is the list of linked features: