Tsi-component-library NPM

test change

Development environment

Commit guidelines

Option A (recommended)

npm run commit - starts CLI with prompts for properly formatting commit message.

Option B (manual)

Git commits should use the following format

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Example:

    git commit -m "feat(Linechart): Linechart card\n Added linechart card create and consume experiencies"

Type

feat: A new feature, release type: minor
fix: A bug fix, release type: patch
docs: Documentation only changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance, release type: patch
test: Adding missing or correcting existing tests
build: Changes that affect the build system
ci: Changes to the CI configuration files and scripts
chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
revert: Reverts a previous commit

Note: If the prefix is feat, fix or perf, it will appear in the changelog. BREAKING CHANGE will always appear in the changelog and will result in a major version bump. Other prefixes are up to your discretion for non-changelog related tasks.

Scope

The scope could be anything specifying place of the commit change. For example tools, adapters, Linechart, Models, etc...

You can use * when the change affects more than a single scope.

Subject

The subject contains succinct description of the change:

use the imperative, present tense: "change" not "changed" nor "changes"
don't capitalize 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.

Recommended VS Code extensions

We recommend you install the following vs-code extensions to streamline the code quality and linting process. |Name|Purpose| |----|-------| |Prettier - Code formatter| Enforces a consistent style by parsing your code and re-printing it. To ensure that this extension is used over other extensions you may have installed, be sure to set it as the default formatter in your VS Code settings. This setting can be set for all languages or by a specific language. To allow for auto-linting on file save, you must have the default formatter set as prettier-vscode and have Editor: format on save checked. These settings can be changed in your VS Code preferences. A JavaScript comment of // prettier-ignore || {/* prettier-ignore */} ||  || /* prettier-ignore */ will exclude the next node in the abstract syntax tree from formatting.| |ESLint| Integrates ESLint into VS Code. If you are new to ESLint check the documentation.| |stylelint| A Visual Studio Code extension to lint CSS/SCSS/Less with stylelint|

Important NPM commands

Command (prefix with `npm run`)	Effect
`build`	Bundles library with rollup.js
`storybook`	Starts Storybook UI component explorer
`test`	Run jest test suite
`test:watch`	Run tests in hot-reloading watch mode
`lint`	Formats code to conform to prettier and stylelint format
`lint:check`	Checks for eslint, prettier, and stylelint formatting errors/warnings.
`generate [componentName]`	Creates template files for new component named componentName
`commit`	`npm run commit` will run an interactive CLI to format your commit message according to the semantic-release guidelines