aiWare Apps
This project contains internal aiWare OS components, javascript SDK and full stack applications. It was generated using Nx.
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, dive deeper, and deeper...
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.
Run 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 @aiware/mylib
.
Should I Make a New Library?
If yes, run nx g @nrwl/react:lib feature-my-feature
to generate your feature. Please keep feature
prefix. Some other prefixes; ui
, data-access
, util
, page
etc.
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
Code scaffolding
Run nx g @nrwl/react:component my-component --project=my-app
to generate a new component.
Shorter version; nx g c AppBar --project=os-sample-app-bar
.
For redux;
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 os-app-bar
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
Run nx g @nrwl/workspace:library
to generate a library.
Libraries are sharable across libraries and applications. They can be imported from @aiware/mylib
.
Use generic scope (like utils/ui) to keep the primary namespace clean. See here how
Please create libraries to define typescript interfaces between apis / libraries / applications.
Request package
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.
Add storybook
Storybook helps with easier development.
Run 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)
Development server
Run 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.
Build
Run nx 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.
Running unit tests
Run nx test my-app-e2e
to execute the unit tests via Jest.
Run nx affected:test
to execute the unit tests affected by a change.
Running end-to-end tests
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.
Understand the workspace
Run 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
Development
SonarLint
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.
Revert
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
Scope
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
- aiware
- js
- ui
- os-sample-app-bar
Use repo for the changes that are outside of packages.
Subject
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
Body
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.
FAQs
Please create a github issue if you have any questions, or something is not working, or not clear here in this file.