What is NX?
🔎 Nx is a set of Extensible Dev Tools for Monorepos.
If you are new to Nx, please go to nx.dev, and watch 10 min overview and complete the tutorial.
If you want to learn more,
- Watch introduction to using nx
- Watch the free egghead course
- Take the advanced course (you need to buy it)
Running the project
- Clone the project, and run
yarnat the project root directory.
- You may run yarn
nx serve [project-name]to start the front end project, and
nx storybook [project-name]to start the storybook development server for isolated component/feature development. Note: project names are usually the path from
/libsdirectories. For example for the project that resides on os/sample-app-bar, the directory project name is
❗❗❗ New Library and Applications ❗❗❗
All new library and application requests, and their namespaces should be reviewed first. This is required as we need to set up external tooling like cypress dashboard and percy manually.
Add your suggested project name to the
.github/semantic file and create a PR. We will discuss the structure, what tools are needed etc, and create external projects/keys and add them to the PR.
⚠️ Note; This change should be against the master, and the PR should only include the addition of the project names to this file. You may still create another branch, add application/libraries you requested. However some refactoring may needed after (could easily be done with the nx mv command)
Generate an application
You probably don't need to generate an application, but if you are creating a brand-new application that will be deployed to Its own subdomain, then you'd need to generate an application.
nx g @nrwl/react:app my-app to generate an application.
When using Nx, you can create multiple applications and libraries in the same workspace.
Generate a feature library
Feature libraries host all the code that is related to that feature. Applications/SDKs should import this features, and use them directly. For example, we could have a checkout page feature, and application could have a route, and render this feature. Libraries are sharable across libraries and applications. They can be imported from
If yes, run
nx g @nrwl/react:lib feature-my-feature to generate your feature. Please keep
feature prefix. Some other prefixes;
⚠️ Note; if some other library is going to depend on this library, you'd need to pass
--buildable flag. We also need to update
tsconfig.lib.json files for the dependencies.
If you are creating aiWare operating system feature, it would look like this;
nx g lib sample-app-bar --directory=os
To create a component;
nx g c AppBar --project=os-sample-app-bar
To create redux slice;
nx g slice sample-app-bar-slice --project=os-sample-app-bar
This feature should also have sub features, react components, redux modules etc. Go here, and see the protal section for the visualization
nx g @nrwl/react:component my-component --project=my-app to generate a new component.
nx g c AppBar --project=os-sample-app-bar.
nx g slice sample-app-bar-slice --project=os-sample-app-bar
Please note that when you create nested project like
os/sample-app-bar, project name becomes
⚠️ Note: use
--dryRun to see what is going to be created.
If you already created bunch off stuff that you want to clean;
Use remove or reset the branch;
git reset --hard HEAD
git clean -f -d
Generate utility library
nx g @nrwl/workspace:library to generate a library.
Libraries are sharable across libraries and applications. They can be imported from
Use generic scope (like utils/ui) to keep the primary namespace clean. See here how
- Request package name (*required)
Please create libraries to define typescript interfaces between apis / libraries / applications.
Procedure to add allowed scope that is required by commit analyzer (which will help us determine versions and generate changelogs). Scope name is you application or library name, and must be kebab-case. Libraries also must have proper prefix. See
contributing.md for more details.
Add new scope name to
.github/semantic.yml, and create a separate PR with only this name change. This PR has to be approved and merged first before you can push your changes to master branch.
Storybook helps with easier development.
nx g @nrwl/react:storybook-configuration [package-name]
Go to package's
.eslintrc.json and add
".storybook/\*" to ignore patterns. Remove this when #3867 is fixed. Please note that this is required for lints to pass (so commit/merge)
We will be following portal like organization (see the link below). All features must be nested under the primary feature.
os/ data-center/ ui/ interfaces/ data-layer/ feature-center/ feature-importer/ feature-exporter/
nx g mv command to move libraries/resturcture them.
nx 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.
nx build my-app to build the project. The build artifacts will be stored in the
--prod flag for a production build.
Running unit tests
nx test my-app-e2e to execute the unit tests via Jest.
nx affected:test to execute the unit tests affected by a change.
Running end-to-end tests
ng e2e my-app to execute the end-to-end tests via Cypress.
nx affected:e2e to execute the end-to-end tests affected by a change.
Understand the workspace
nx dep-graph to see a diagram of the dependencies of your projects.
☁ Nx Cloud
Computation Memoization in the Cloud
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.
More resources on Nx
- Visit the Nx Documentation to learn more.
This project is checked by SonarCloud. Use sonar cube and sonar lint plugins if you don't want your code fail on CI. Plugins are available for popular IDEs including VS Code and WebStorm
Commit Message Format
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 header is mandatory and the scope of the header is also mandatory.
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.
The footer should contain a closing reference to an issue if any.
Samples: (even more samples)
docs(changelog): update changelog to beta.5
fix(release): need to depend on latest rxjs and zone.js The version in our package.json gets copied to the one we publish, and users need the latest of these.
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.
Type [bookmark this]
Must be one of the following:
- build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
- ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
- docs: Documentation only changes
- feat: A new feature
- fix: A bug fix
- perf: A code change that improves performance
- refactor: A code change that neither fixes a bug nor adds a feature
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- test: Adding missing tests or correcting existing tests
The scope should be the name of the package affected (as perceived by the person reading the changelog generated from commit messages.
The following is the list of supported scopes:
- repo (means repository, affecting all projects))
Use repo for the changes that are outside of packages.
The subject contains a succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize the 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 and is also the place to reference GitHub issues that this commit Closes.
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.
Use IDE plugins to get the format correct, It's hard to remember, and CI will fail if we don't get it right.
aiWARE.js releases are automated as of today, and any push to feature/* branches will trigger a release in non production distribution channels.
Any push to master branch will trigger alpha release as we are just starting to build these components. We will change it to latest when we do initial production release. Production releases are need to be triggered manually for now (under github workflows/release). We could also automate it in the feature when we are comfortable with our CI/CD process.
Please create a github issue if you have any questions, or something is not working, or not clear here in this file.