chore: initial commit

.eslintignore

@@ -0,0 +1,21 @@
+# dependencies
+node_modules
+.pnp
+.pnp.js
+
+# testing
+coverage
+
+# production
+lib
+
+# misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

.eslintrc

@@ -0,0 +1,3 @@
+{
+  "extends": ["react-app", "react-app/jest"]
+}

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,30 @@
+name: 🐛 Bug Report
+description: Something isn't working correctly.
+body: 
+  - type: markdown
+    attributes:
+      value: |
+        Thank you for contributing to open source!
+
+        Think you found a bug?
+        ======================
+        The best bug report is a failing test in the repository as a pull request. Otherwise, please use the form below.
+  - type: textarea
+    attributes:
+      label: What version of Contract Store are you using?
+      value: |
+        - Contract Store:
+    validations:
+      required: true
+  - type: textarea
+    attributes:
+      label: What is the current behavior?
+      description: |
+        If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies. Paste the link to a CodeSandbox (https://codesandbox.io/s/new) example below
+    validations:
+      required: true
+  - type: textarea
+    attributes:
+      label: What is the expected behavior?
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,19 @@
+name: 👍 Feature Request
+description: I'd like Contract Store to do something new.
+body: 
+  - type: markdown
+    attributes:
+      value: |
+        Thank you for contributing to open source!
+  - type: textarea
+    attributes:
+      label: What is the new or updated feature that you are suggesting?
+      description: |
+        Please provide thoughtful commentary *and code samples* on what this feature means for your product. What will it allow you to do that you can't do today? How will it make current work-arounds straightforward? What potential bugs and edge cases does it help to avoid? etc. Please keep it product-centric.
+    validations:
+      required: true
+  - type: textarea
+    attributes:
+      label: Why should this feature be included?
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/questions_and_help.yml

@@ -0,0 +1,12 @@
+name: 🤔 Questions and Help
+description: The place to ask and / or say anything.
+body: 
+  - type: markdown
+    attributes:
+      value: |
+        Thank you for contributing to open source!
+  - type: textarea
+    attributes:
+      label: Open
+    validations:
+      required: true

.github/workflows/alpha.yml

@@ -0,0 +1,50 @@
+name: Alpha Build
+on:
+  push:
+    branches:
+      - alpha
+jobs:
+  setup:
+    runs-on: ubuntu-latest
+    name: Setup
+    steps:
+      - uses: actions/checkout@v2
+      - name: Setup node
+        uses: actions/setup-node@v2
+        with:
+          node-version: '16.x'
+          cache: npm
+      - run: npm ci
+  test:
+    runs-on: ubuntu-latest
+    needs: [setup]
+    name: Test
+    steps:
+      - uses: actions/checkout@v2
+      - name: Setup node
+        uses: actions/setup-node@v2
+        with:
+          node-version: '16.x'
+          cache: npm
+      - run: npm ci
+      - run: npm run build
+      - run: npm test
+      - run: npm run test:cover
+  publish:
+    runs-on: ubuntu-latest
+    name: Versionning and Publish
+    needs: [test]
+    steps:
+      - uses: actions/checkout@v2
+      - name: Setup node
+        uses: actions/setup-node@v2
+        with:
+          node-version: '16.x'
+          cache: npm
+      - run: npm ci
+      - run: npm run build
+      - name: Release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
+        run: npx semantic-release

.github/workflows/main.yml

@@ -0,0 +1,66 @@
+name: Main Build
+on:
+  push:
+    branches:
+      - main
+jobs:
+  setup:
+    runs-on: ubuntu-latest
+    name: Setup
+    steps:
+      - uses: actions/checkout@v2
+      - name: Setup node
+        uses: actions/setup-node@v2
+        with:
+          node-version: '16.x'
+          cache: npm
+      - run: npm ci
+  test:
+    runs-on: ubuntu-latest
+    needs: [setup]
+    name: Test
+    steps:
+      - uses: actions/checkout@v2
+      - name: Setup node
+        uses: actions/setup-node@v2
+        with:
+          node-version: '16.x'
+          cache: npm
+      - run: npm ci
+      - run: npm run build
+      - run: npm test
+  coverage:
+    runs-on: ubuntu-latest
+    needs: [test]
+    name: Coverage
+    steps:
+      - uses: actions/checkout@v2
+      - name: Setup node
+        uses: actions/setup-node@v2
+        with:
+          node-version: '16.x'
+          cache: npm
+      - run: npm ci
+      - run: npm run test:cover
+      - name: Coveralls
+        uses: coverallsapp/github-action@master
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+  publish:
+    runs-on: ubuntu-latest
+    name: Versionning and Publish
+    needs: [test]
+    steps:
+      - uses: actions/checkout@v2
+      - name: Setup node
+        uses: actions/setup-node@v2
+        with:
+          node-version: '16.x'
+          cache: npm
+      - run: npm ci
+      - run: npm run build
+      - name: Release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
+        run: npx semantic-release

.github/workflows/pr.yml

@@ -0,0 +1,30 @@
+name: Pull Request Build
+on:
+  pull_request:
+jobs:
+  setup:
+    runs-on: ubuntu-latest
+    name: Setup
+    steps:
+      - uses: actions/checkout@v2
+      - name: Setup node
+        uses: actions/setup-node@v2
+        with:
+          node-version: '16.x'
+          cache: npm
+      - run: npm ci
+  test:
+    runs-on: ubuntu-latest
+    needs: [setup]
+    name: Test
+    steps:
+      - uses: actions/checkout@v2
+      - name: Setup node
+        uses: actions/setup-node@v2
+        with:
+          node-version: '16.x'
+          cache: npm
+      - run: npm ci
+      - run: npm run build
+      - run: npm test
+      - run: npm run test:cover

.gitignore

@@ -0,0 +1,25 @@
+# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
+
+# dependencies
+/node_modules
+/.pnp
+.pnp.js
+
+# testing
+/coverage
+
+# production
+/lib
+
+# misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+.env*

.nvmrc

@@ -0,0 +1 @@
+v16

.prettierrc

@@ -0,0 +1,4 @@
+{
+    "useTabs": false,
+    "tabWidth": 2
+}

.releaserc.yml

@@ -0,0 +1,3 @@
+{
+  "branches": ["main", { name: 'alpha', prerelease: true }]
+}

CONTRIBUTING.md

@@ -0,0 +1,111 @@
+# Contributing
+
+## Questions
+
+If you have questions about implementation details, help or support, then please open an issue with your question.
+
+## Reporting Issues
+
+If you have found what you think is a bug, please [file an issue](https://github.com/VGLoic/contract-store/issues/new).
+
+## Suggesting new features
+
+If you are here to suggest a feature, first create an issue if it does not already exist. From there, we will discuss use-cases for the feature and then finally discuss how it could be implemented.
+
+## Development
+
+If you have been assigned to fix an issue or develop a new feature, please follow these steps to get started:
+
+- Fork this repository
+- Set up the proper Node version by running `$ nvm use`
+- Install dependencies by running `$ npm install`
+- Implement your changes and tests to files in the `src/` directory and corresponding test files
+- To run examples, follow their individual directions.
+- Git stage your required changes and commit (see below commit guidelines)
+- Submit PR for review
+
+## Commit message conventions
+
+`contract-store` is using [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines).
+
+We have very precise rules over how our git commit messages can be formatted. This leads to **more readable messages** that are easy to follow when looking through the **project history**.
+
+### 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 optional.
+
+Any line of the commit message cannot be longer than 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.
+
+### Type
+
+Must be one of the following:
+
+- **feat**: A new feature
+- **fix**: A bug fix
+- **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
+- **test**: Adding missing or correcting existing tests
+- **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
+  generation
+
+### Scope
+
+The scope could be anything specifying place of the commit change.
+
+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](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue).
+
+**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.
+
+### Example
+
+Here is an example of the release type that will be done based on a commit messages:
+
+| Commit message                                                                                                                                                                                   | Release type               |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------- |
+| `fix(pencil): stop graphite breaking when too much pressure applied`                                                                                                                             | Patch Release              |
+| `feat(pencil): add 'graphiteWidth' option`                                                                                                                                                       | ~~Minor~~ Feature Release  |
+| `perf(pencil): remove graphiteWidth option`<br><br>`BREAKING CHANGE: The graphiteWidth option has been removed.`<br>`The default graphite width of 10mm is always used for performance reasons.` | ~~Major~~ Breaking Release |
+
+### 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.
+
+## Pull requests
+
+Maintainers merge pull requests by squashing all commits and editing the commit message if necessary using the GitHub user interface.
+
+Use an appropriate commit type. Be especially careful with breaking changes.
+
+## Releases
+
+For each new commit added to `main` with `git push` or by merging a pull request or merging from another branch, a GitHub action is triggered and runs the `semantic-release` command to make a release if there are codebase changes since the last release that affect the package functionalities.