Components/tooling choices

This is a non-exhaustive list of components and tooling we could use to improve maintainability and sustainability of discipl libraries, organized per topic in suggested rough order of priority. Feel free to edit this post/add remarks in comments.

Libraries and Applications:

- [x] Test framework (#13, #14)
- [x] Continuous Integration (#9)
- [x] Style guide (and linter) (#16)
- [ ] Documentation (#21)
- [x] Code coverage (#17)
- [ ] Badges
- [x] Quality Gate (a19e428977262518725892d81c0b43b35f0b55af, #19)
- [ ] Publishing to npm (and using semver)
- [ ] Contributor Guidelines

Applications:

- [ ] i18n
- [ ] Containerization
- [ ] end-to-end tests

## Test Framework

Possibilities:
- ~~Jasmine~~
- Mocha+Chai

In both cases Karma is the de-facto test runner used by many projects.

Mocha+Chai has been chosen for flexibility.

## Continuous Integration

Travis has solid support for GitHub and open source projects. #9 shows how it could be added.
I've heard good things about Circle CI, which offers 4 free concurrent builds for open source projects. GitLab CI/CD is also a possibility (even without using GitLab for code hosting)

## Style guide and linter

There are a couple of alternatives out there, main ones being [AirBnB](https://github.com/airbnb/javascript), [Google](https://google.github.io/styleguide/jsguide.html) and [standard](https://github.com/standard/standard). The AirBnB one starts with "this guide assumes you're using babel", which we are not at library level. Between Google and standard, standard seems to have a lot of nice integrations, and is low-config, with the possibility to eject to an eslint config if we decide we want to customize rules.

## Documentation

There are some JSDoc comments, which could be used to auto-generate documentation. Given how long the README is, a "Content" section with anchor links probably wouldn't hurt.

Options:

- Use JSDoc (generates HTML)
- Host through GitHub Pages
- Host independently from GitHub (i.e. discipl.org)
- Use jsdoc-to-markdown
- Host raw from repo (i.e. link to the file, which will be rendered in GitHub)
- Host with GitHub Pages
- Embed in a bigger site, hosted independently from GitHub (using e.g. GitBook)

## Code coverage

Karma as a test runner can provide code coverage using istanbul. The only alternative to istanbul I could find was [c8](https://github.com/bcoe/c8), which uses coverage exposed by the v8 engine. This does require the latest version of node, and might require some engineering to get working with a test runner.

## Badges

More of a thing per topic, actually. More or less every other component on this list could have a badge. Essential would be CI and coverage badges. Style/linter, quality and an npm badge are also possible.

## Quality gate

[SonarCloud](https://sonarcloud.io/about) offers free quality checks for open source projects. I'm not aware of a suitable alternative.

## Npm and semver

Currently a lot of the components are referenced using git-links. This is probably doable for now, but not sustainable in the long run. Publishing to npm does add some overhead, but allows clearer versioning and allows others to easily start using discipl.

With respect to semver, I propose to use 0.x.y for now. I have also seen projects where the minor version is then used for breaking changes and the patch version is used for non-breaking changes, even though this is not required by semver.

## Contributor guidelines

Not of the highest priority right now. Items that could contribute to this are: Code of Conduct, Issue and/or Pull Request templates.

## i18n

Specific technologies would depend on choice of frameworks.

## Containerization

Docker. Using multi-stage builds is a good way to containerize the build process while also obtaining a slim deliverable.

## End to end tests

Specific technologies would depend on choice of frameworks