This project was generated with Angular CLI using Nrwl Nx.
Before start
- Install some useful global dependencies:
Watch a 5-minute video on how to get started with Nrwl Nx.
When using Nx, you can create multiple applications and libraries in the same CLI workspace.
- Run
ng g application <name>
to generate an application in the current workspace. - Run
ng g library <name>
to generate an new library project in the current workspace.
Run ng s 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 s
for running the defaultProject defined on the workspace configuration.
Run ng g <schematic> <name> --project=<name>
to generate and/or modify files based on a schematic.
Some of the schematics available are:
- Run
ng g component
to generate a new component. - Run
ng g directive
to generate a new directive. - Run
ng g pipe
to generate a new pipe. - Run
ng g service
to generate a new service. - Run
ng g class
to generate a new class. - Run
ng g guard
to generate a new guard. - Run
ng g interface
to generate a new interface. - Run
ng g enum
to generate a new enum. - Run
ng g module
to generate a new module.
Run ng lint my-app
to lint the project.
- Run
nx affected:lint
lint affected apps and libs. - Run
yarn affected:lint:parallel
to lint affected apps and libs, in parallel.
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
nx affected:build
to build affected apps and libs. - Run
yarn affected:build:parallel
to build affected apps and libs, in parallel.
- Run
yarn affected:build:stag
to build affected apps and libs for staging. - Run
yarn affected:build:stag:parallel
to build affected apps and libs for staging, in parallel.
- Run
yarn affected:build:prod
to build affected apps and libs for production. - Run
yarn affected:build:prod:parallel
to build affected apps and libs for production, in parallel.
- Run
ng test <lib|app>
to execute the unit tests via Jest. - Run
ng test <lib|app> -t=<regex>
to execute only tests with a name that matches the regex. - Run
ng test <lib|app> --test-file path/to/file.spec.ts
to execute a single file. - Run
ng test <lib|app> --verbose ..
to display individual test results with the test suite hierarchy. - Run
ng test <lib|app> --pass-with-no-tests ..
that allows the test suite to pass when no files are found.
In case of no tests found, avoids failure in CI by setting the passWithNoTests variable at jest.config.js
- Run
nx affected:test
to execute the unit tests affected by a change. - Run
yarn affected:test:parallel
to execute the unit tests affected by a change in parallel. - Run
yarn affected:test:parallel
to execute the unit tests affected by a change, in parallel.
IMPORTANT:
Ensure that your yarn global packages are in sync with the package.json:
- Run
yarn global list
and verify, specially:
Run ng e2e my-app-e2e
to execute the end-to-end tests via Cypress.
Before running the tests make sure you are serving the app via ng serve
.
We use semantic-release to automate the whole package release workflow including:
- Determining the next version number
- Generating the release notes
- Publishing the package
Run npx semantic-release --dry-run --no-ci --debug
to skip publishing, print next version, release notes and debugging information.
Get to know more here.
Run yarn release
, which will:
- Fetch, prune and force checkout the
develop
branch - Force checkout the
master
branch - Fast-Forward merge the
develop
into themaster
branch - Load the GH_TOKEN from the local .env file
- Run the semantic-release script
- Merge the
master
into thedevelop
branch - Push
develop
to remote
To get more help on the Angular CLI use ng help
or go check out the Angular CLI README.
This is a monorepo project built with Nrwl Nx.
From the Nrwl Nx docs:
Developing Like Google, Facebook, and Microsoft
Working with multiple applications and libraries is difficult. From Google to Facebook, Uber, Twitter and more, a good amount of large software companies handle this challenge by taking a monorepo approach. And they have been doing so for years. These are some of the advantages this approach provides:
- Everything at that current commit works together. Changes can be verified across all affected parts of the organization.
- Easy to split code into composable modules
- Easier dependency management
- One toolchain setup
- Code editors and IDEs are "workspace" aware
- Consistent developer experience
- Read the Angular Enterprise Monorepo Patterns Book
- Keep up with the Nrwl Blog
- Keep up with the Nrwl YouTube Channel
- Follow the Github Flow.
- Follow the Git Rebase Workflow.
- Follow the Successfull Git Branch Model's branch naming conventions.
- Write your code in TypeScript.
- Configure TSLint on your code editor.
- Use Yarn to manage dependencies.
- Use English for coding, commenting and committing.
- Write readable and S.O.L.I.D. code.
- Follow the General Coding Guidelines,
- Follow the General Naming Guidelines
- Follow the Angular Style Guide - as much as possible.
- Prettier
- Takes care of code formatting
- Rules are configured on
.prettierrc.yml
- TSLint
- Takes care of linting rules
- Rules are configured on
.tslint.yml
- Saas Lint
- Linter for both sass and scss syntax
- Rules are configured on
.sass-lint.yml
- LintHTML
- An unofficial html5 linter and validator
- Rules are configured on
.linthtmlrc.yml
- Markdown Lint
- Style checker and lint tool for Markdown/CommonMark files
- Rules are configured on
.markdownlint.yml
- Commit Lint
- Linter for commit messages
- Rules are configured on
.commitlintrc.yml
To propose a new rule or a code style change, please:
- Open a pull request
- On the PR title:
- A summary of the change
- On the PR description:
- Describe the problem you want to solve.
- Your take on the correct solution to the problem.
- Any relevant resource that would endorse such a change
- Add a commit providing 2-3 examples for the proposed solution
- Preferably on a real code
- Request the review for the change for teammates
- Being approved by 51% of the teammates:
- Configure the rule properly;
- Apply the rule on the whole codebase on the project;
- And the PR follows the regular Pull Request flow; YAY!
- Write unit tests with Jest.
- Write E2E tests with Cypress.
- Apply the Better Specs best practices for testing - as much as possible.
- Follow the Conventional Commits
- Follow the Angular Commit Message Guidelines
- Follow the How to Write a Git Commit Message tips
- Follow the 5 Useful Tips For A Better Commit Message tips
- Consider using Commitizen cli
Follow The seven rules of a great Git commit message (TL;DR)
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
As configured on .commitlintrc.yml
, it must be one of the following:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- ref: A code change that neither fixes a bug nor adds a feature
- test: Adding missing tests or correcting existing tests
- revert: A commit that reverts a previous commit
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
- ci: Changes to our CI configuration files and scripts (example scopes: Circle, BrowserStack, SauceLabs)
- build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
- perf: A code change that improves performance
- git: Changes on git files, such as
.gitignore
- Commit often
- Keep commits small and atomic
- Write S.O.L.I.D. commits
- Write meaningful titles targeting for non-technical readers
- Write commits that would help the Code Review
- Add any extra information that would help the Code Review
- Reference the issue that originated the commit
One would say that some of the main purposes of Pull Requests are:
- Add a product increment
- Remove obsolete code/behaviour
- Fix a product problem
- Enhance product behaviour
- Refactor code to improve quality
- Add/change some architecture requirement
- Update libraries or improve security
- Discuss the better approach to certain issues
The ideal PR must be:
- As smallest as possible
- Defects free
- Easy to be reviewed and validated
- Reviewed and validated as soon as possible
- Merged as soon as possible
- Have been approved by at least one reviewer
- Prefer one feature/fix/refactoring per PR
- Estimate the PR before starting it
- Link the PR to an Issue before starting it
- Comment any consideration/doubt/problem/discussion/definition on the PR`s Issue;
- Try to have, at least, one Unit Tests per change, when applicable
- Try to make a PR that you would enjoy reviewing
- Remember, the next reviewer can be you
Before sending the PR to Code Review ensures that
- Any implementation follows the Coding Best Practices and any team
Style Guide
- Any commit follows the Commit Best Practices
- Any change has been tested at least once. That is:
- Running the program
- Checking if the change works
- All project's Unit Tests are keeping running
- There are no linter violations on the project
- You have reviewed your own code
To Get Better Code Review ensures that
- The PR has:
- The minimum changes necessary to accomplish the PR`s goal
- The minimum commits necessary to accomplish the PR`s goal
- A clear, short and concise title that summarizes the changes
- A clear description that contextualizes the problem you’re solving
- Any relevant explanation or reference is present on the PR`s description or commits;
- Whenever necessary, the PR describes how it must be validated
- Adding any relevant info necessary to the validation, such as username, environment, password, deadline, and etc.
- Avoid refactorings not related to the PR's goal
- Because it might difficult the Code Review
- However, if the refactoring is inevitable
- It should be properly isolated and justified
One would say that some of the main purposes of Code Reviews are:
- Detecting and Reducing defects
- Sharing knowledge on the architecture, business logic, design patterns, and techniques
- Promoting the collective ownership of the code
- Try to understand the change and its impact on the codebase and on the product
- For each change, ensures that
- It is clear
- It mets the requirements
- It has no defects
- It has, at least, one unit test
- It follows the Coding Best Practices
- For each commit, ensures that
- It follows the Commit Best Practices
When reviewing a Pull Request, try to:
- Focus more on finding
- Defects
- Logic problems
- Performance issues
- Bugs
- Focus less on
- Changes that have not been made on the commit
- Things not related to the Pull Request goal
- Coding style
- Nitpicking
- Give, at least, one comment. When so, try to:
- Ask, don't tell
- Highlight wins
- Highlight things that you've learnt
- Articulate the problems (if any) and suggest alternatives
- Mind your language and tone
- It is incredibly easy to misunderstand something online
- Remember:
- It is perfectly possible to have more than one way of solving a problem
- Code Reviews are more efficient when focusing on defects rather than code style
- Code Styles should be ruled automatically by tools. That is:
- If a code has no error, performance issue, defect, nor violates any linter rule, it is probably ok
- Some ideas are better conveyed face-to-face
- You might have to maintain this change in the near future
Here are some highly recommended resources on the topic:
- Implementing a Strong Code-Review Culture by Derek Prior
- Goldilocks And The Three Code Reviews by Vaidehi Joshi
- Code Review is an Architectural Necessity - GitHub Universe 2016
- How to Give and Get Better Code Reviews
- Abide by the Contributor Covenant code of conduct.