initial commit

.circleci/config.yml

@@ -0,0 +1,27 @@
+version: 2
+jobs:
+  build:
+    working_directory: ~/project
+    docker:
+      - image: circleci/node:latest
+    branches:
+      ignore:
+        - gh-pages # list of branches to ignore
+        - /release\/.*/ # or ignore regexes
+    steps:
+      - checkout
+      - restore_cache:
+          key: dependency-cache-{{ checksum "yarn.lock" }}
+      - run:
+          name: install dependences
+          command: yarn
+      - save_cache:
+          key: dependency-cache-{{ checksum "yarn.lock" }}
+          paths:
+            - ./node_modules
+      - run:
+          name: test
+          command: yarn test
+      - run:
+          name: release
+          command: npx semantic-release

.eslintignore

@@ -0,0 +1 @@
+node_modules/

.eslintrc.js

@@ -0,0 +1,3 @@
+module.exports = {
+  "extends": "standard"
+}

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,38 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Desktop (please complete the following information):**
+ - OS: [e.g. iOS]
+ - Browser [e.g. chrome, safari]
+ - Version [e.g. 22]
+
+**Smartphone (please complete the following information):**
+ - Device: [e.g. iPhone6]
+ - OS: [e.g. iOS8.1]
+ - Browser [e.g. stock browser, safari]
+ - Version [e.g. 22]
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.gitignore

@@ -0,0 +1,21 @@
+.DS_Store
+node_modules
+/dist
+
+# local env files
+.env.local
+.env.*.local
+
+# Log files
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# Editor directories and files
+.idea
+.vscode
+*.suo
+*.ntvs*
+*.njsproj
+*.sln
+*.sw?

BUILDING.md

@@ -0,0 +1,92 @@
+# Building
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
+
+This document is licensed under [The Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0.html).
+
+## Introduction
+
+This document is to describe the functionality a project MUST provide in terms of creating build artifacts. It also describes the structure in which project's MUST write build artifacts in.
+
+A project MUST provide:
+
+ - a folder name convention for build artifacts
+ - a folder structure for the above-mentioned build artifacts folder
+ - a list of targets
+ - a file called `bin/build.{target}.{ext}` to target each of the build targets
+ - a build pipeline given the above pretext
+
+The purpose of having a uniform way of producing a build is that we may ALL produce builds for any of the projects, making the onramp for new developers less steep, while still maintaining an exceptionally high level of quality.
+
+The projects should follow the 'architecture as code' principle - and should require a very minimal set of dependencies. 
+
+It is the responsibilty of the build tooling to write artifacts to the appropriate location as outlined in this specification.
+
+## Build Folder Name
+
+The cannonical folder for builds SHALL be named `build` and be located at the root of the project repository.
+Each project MUST `git ignore` the `build` folder.
+
+## Build Folder Structure
+
+Files and folder names MUST be lowercase.
+The result of the build process should create a folder structure as follows:
+
+```
+.
+└── build
+    └── {target}
+        └── {project-name}.{ext}
+```
+
+
+Below is an example:
+```
+.
+└── build
+    └── windows
+        └── my-build.exe
+```
+
+## Build Targets
+
+Below is a list of suggested targets for a project
+1. windows
+2. linux
+3. macos
+
+## Build script
+
+Each release target MUST have a `bin/build.{target}.{ext}` file.
+
+The result of this is that every project MUST produce a build for each target when the following command is invoked:
+
+```
+bin/build.{target}.{ext}
+```
+
+The file MUST be placed in the project's `bin` directory.
+
+## Build Pipeline
+
+### Building targets
+
+`bin/build.{target}.{ext}` should create builds for each of the targets, and place the build artifacts in a folder structure outlined above.
+
+### Windows
+
+```
+bin/build.windows.bat
+```
+
+### Linux
+
+```
+bin/build.linux.sh
+```
+
+### Macos
+
+```
+bin/build.macos.sh
+```

CONTRIBUTING.md

@@ -0,0 +1,61 @@
+# Contributing
+
+> This document is inspired by [elasticsearch/CONTRIBUTING.md](https://github.com/elastic/elasticsearch/blob/master/CONTRIBUTING.md)
+
+Adding a `CONTRIBUTING.md` to a Github repository enables a link to that file in the pull request or create an issue page. This document should guide potential contributors toward making a successful and meaningful impact on the project, and can save maintainers time and hassle caused by improper pull requests and issues. You can learn more about the features that are enabled by Github when this file is present [here](https://help.github.com/articles/setting-guidelines-for-repository-contributors/).
+
+## How to contribute
+
+There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, [submitting Github issues](https://help.github.com/articles/creating-an-issue/), bug reports, feature requests and writing code.
+
+## License
+
+This repository uses the [The Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0.html).
+
+## Bug reports
+
+If you think you've found a bug in the software, first make sure you're testing against the *latest* version of the software -- your issue may have been fixed already. If it's not, please check out the issues list on Github and search for similar issues that have already been opened. If there are no issues then please [submit a Github issue](https://help.github.com/articles/creating-an-issue/).
+
+If you can provide a small test case it would greatly help the reproduction of a bug, as well as a a screenshot, and any other information you can provide.
+
+
+## Feature Requests
+
+If there are features that do not exist yet, we are definitely open to feature requests and detailed proposals. [Open an issue](https://help.github.com/articles/creating-an-issue/) on our Github which describes the feature or proposal in detail, answer questions like why? how?
+
+## Contributing Code and Documentation Changes
+
+Bug fixes, patches and new features are welcome. Please find or open an issue about it first. Talk about what exactly want to do, someone may already be working on it, or there might be some issues that you need to be aware of before implementing the fix.
+
+There are many ways to fix a problem and it is important to find the best approach before writing a ton of code.
+
+##### Documentation Changes
+
+For small documentation changes and fixes, these can be done quickly following this video guide on [how to contribute to Open Source in 1 minute on Github](https://www.youtube.com/watch?v=kRYk1-yKwWs).
+
+### Forking the repository
+
+[How to fork a repository](https://help.github.com/articles/fork-a-repo/).
+
+### Submitting changes
+
+1. Review & Test changes
+    * If the code changed, then test it. If documentation changed, then preview the rendered Markdown.
+2. Commiting
+    * Follow the [Conventional Commits](CONVENTIONAL_COMMITS.md) guidelines to create a commit message.
+3. Sign the CLA
+    * Make sure you've signed the repository's Contributor License Agreement. We are not asking you to assign copyright to us, but to give us the right to distribute your code without restriction. We ask this of all contributors in order to assure our users of the origin and continuing existence of the code. You only need to sign the CLA once.
+4. Submit a pull request
+    * Push local changes to your forked repository and make a pull request. Follow the [Convention Commits](CONVENTIONAL_COMMITS.md) guidelines for naming Github pull requests and what to put in the body.
+
+
+## Building
+
+Follow the build process is outlined in [BUILDING.md](BUILDING.md) to create a build.
+
+
+## Releasing
+
+Follow the release process is outlined in [RELEASING.md](RELEASING.md) to create a release.
+
+