Komponentbibliotek for Grep. Brukes i Læreplanutvikleren og Grepadmin.
npm i grep-components
- Bundles
cjsandesmodule formats - create-react-app for example usage and local dev
- Rollup for bundling
- Babel for transpiling
- Jest & React Testing Library for testing
- Typescript
- Sourcemap creation
- Storybook for easy development of components
- commitlint to enforce the conventional commit format
- semantic-release for version management and package publishing
- Github Actions for running build, test and release jobs
- Dependabot for dependency management
Pushing to master or any feature-branch (feature/some-feature) will automatically run the release-workflow. This will build the package, analyze the commits to determine next version number and publish the new version to NPM and Github. Current and previous runs can be seen here.
Semantic-release will determine the next version number by looking at the commit message prefix:
| Prefix | Release type | Example commit message |
|---|---|---|
| 'BREAKING CHANGE: ' in commit message footer | Major release | revert: Reverting some changes BREAKING CHANGE: this revert will break something |
| feat | Minor release | feat: Some minor changes |
| fix, perf, revert, refactor, build/chore(deps*) | Patch release | fix: Some fixes |
If a commit contains none of these, then no release will be created / published.
The release-workflow can also be manually triggered from here, but will still only release if there is a commit with a valid prefix.
- Feature-branches have to start with
feature/to be included in the release-workflow. Example:feature/some-feature - Published versions from a valid feature-branch will get the branch-name, excluding the
feature/part, as a dist-tag in NPM. Example:feature/some-featureon version 0.18.0 will become0.18.0-some-feature.1and can be installed by runningnpm i grep-components@some-feature