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.

• Request package name

• Add storybook (optional)

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

• Request package name (*required)

• Add storybook (*optional)

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

• Request package name (*required)

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

• https://github.com/nrwl/nx
• https://github.com/nrwl/nx-examples
• https://blog.nrwl.io/ui-testing-with-storybook-and-nx-4b86975224c
• https://blog.nrwl.io/storybook-support-run-many-command-ui-improvements-and-more-in-nx-8-8-90575cb5dda4
• https://nx.dev/latest/react/plugins/storybook/overview
• https://blog.nrwl.io/publishing-react-libraries-made-easy-d5b3d013deba
• https://cdn2.hubspot.net/hubfs/2757427/effective-react-with-nx-preview.v0.5.pdf?utm_campaign=Book%3A%20React%20Monorepo%20Patterns%2C%20August%202019&utm_medium=email&_hsenc=p2ANqtz--N9q7xdh1VcNKETmieaSEQ9HyPCswOGlzhGq48Z0ew7wTQMiUIwlh8zymAoLB6q6EyYN-yLuyTz7snPEbg0E9RuupNRw&_hsmi=85981636&utm_content=85981636&utm_source=hs_automation&hsCtaTracking=ce74725b-f491-487f-8e6b-8789ba45536e%7C8ec9f768-c2f8-4769-81fd-d90ca615b501
• https://nx.app/orgs/5f870bb6a0ef9a00056a6f4e/workspaces/5f8e5268eb478702a11ee62b/report
• https://www.youtube.com/channel/UCF8luR7ORJTCwSNA9yZksCw
• Visit the Nx Documentation to learn more.

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.

Footer

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.