third_random_beta_app

[![Lines of Code](https://sonarcloud.io/api/project_badges/measure?project=aiware-apps&metric=ncloc&token=7d766c19032706ddb69217fbc9dd466846d8a39f)](https://sonarcloud.io/dashboard?id=aiware-apps) [![Maintainability Rating](https://sonarcloud.io/api/proje

Usage no npm install needed!

<script type="module">
  import thirdRandomBetaApp from 'https://cdn.skypack.dev/third_random_beta_app';
</script>

README

aiWARE Apps

Lines of Code Maintainability Rating Reliability Rating Security Rating Quality Gate Status Technical Debt Vulnerabilities Coverage Code Smells Duplicated Lines (%) Bugs

This project contains internal aiWARE OS components, javascript SDK and full stack applications. It is using Nx to manage the monorepo.

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,

Running the project

  1. Clone the project, and run yarn at the project root directory.
  2. 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 /apps, and /libs directories. For example for the project that resides on os/sample-app-bar, the directory project name is os-sample-app-bar.

❗❗❗ 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.

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.

⚠ī¸ 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.base.json / 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

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)

Structuring Projects

We will be following portal like organization (see the link below). All features must be nested under the primary feature.

For example;

os/ data-center/ ui/ interfaces/ data-layer/ feature-center/ feature-importer/ feature-exporter/

See more here; https://nx.dev/latest/angular/guides/monorepo-nx-enterprise#code-organization-amp-naming-conventions

Move Library

Run nx g mv command to move libraries/resturcture them.

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 (means repository, affecting all projects))
  • deps
  • aiware
  • js-core
  • js-constants
  • js-interfaces
  • ui
  • shared-theme
  • shared-store
  • os-sample-app-bar
  • os-sample-panels
  • os-flow-center
  • os-flow-widget

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.

TMI

Use IDE plugins to get the format correct, It's hard to remember, and CI will fail if we don't get it right.

Release

aiWARE.js

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.

FAQs

Please create a github issue if you have any questions, or something is not working, or not clear here in this file.