{"action":"created","issue":{"url":"https://api.github.com/repos/discipl/core/issues/12","repository_url":"https://api.github.com/repos/discipl/core","labels_url":"https://api.github.com/repos/discipl/core/issues/12/labels{/name}","comments_url":"https://api.github.com/repos/discipl/core/issues/12/comments","events_url":"https://api.github.com/repos/discipl/core/issues/12/events","html_url":"https://github.com/discipl/core/issues/12","id":391123129,"node_id":"MDU6SXNzdWUzOTExMjMxMjk=","number":12,"title":"Components/tooling choices","user":{"login":"pimotte","id":5917458,"node_id":"MDQ6VXNlcjU5MTc0NTg=","avatar_url":"https://avatars0.githubusercontent.com/u/5917458?v=4","gravatar_id":"","url":"https://api.github.com/users/pimotte","html_url":"https://github.com/pimotte","followers_url":"https://api.github.com/users/pimotte/followers","following_url":"https://api.github.com/users/pimotte/following{/other_user}","gists_url":"https://api.github.com/users/pimotte/gists{/gist_id}","starred_url":"https://api.github.com/users/pimotte/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pimotte/subscriptions","organizations_url":"https://api.github.com/users/pimotte/orgs","repos_url":"https://api.github.com/users/pimotte/repos","events_url":"https://api.github.com/users/pimotte/events{/privacy}","received_events_url":"https://api.github.com/users/pimotte/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2018-12-14T14:02:26Z","updated_at":"2018-12-17T16:18:09Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"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.\r\n\r\nLibraries and Applications:\r\n\r\n- [ ] Test framework\r\n- [x] Continuous Integration (#9)\r\n- [ ] Style guide (and linter)\r\n- [ ] Documentation \r\n- [ ] Code coverage\r\n- [ ] Badges\r\n- [ ] Quality Gate\r\n- [ ] Publishing to npm (and using semver)\r\n- [ ] Contributor Guidelines\r\n\r\nApplications:\r\n\r\n- [ ] i18n \r\n- [ ] Containerization\r\n- [ ] end-to-end tests\r\n\r\n\r\n## Test Framework\r\n\r\nPossibilities:\r\n- ~~Jasmine~~\r\n- Mocha+Chai\r\n\r\nIn both cases Karma is the de-facto test runner used by many projects. \r\n\r\nMocha+Chai has been chosen for flexibility.\r\n\r\n## Continuous Integration\r\n\r\nTravis has solid support for GitHub and open source projects. #9 shows how it could be added.\r\nI'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)\r\n\r\n## Style guide and linter\r\n\r\nThere 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.\r\n\r\n## Documentation\r\n\r\nThere 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.\r\n\r\n## Code coverage\r\n\r\nKarma 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.\r\n\r\n## Badges\r\n\r\nMore 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.\r\n\r\n## Quality gate\r\n\r\n[SonarCloud](https://sonarcloud.io/about) offers free quality checks for open source projects. I'm not aware of a suitable alternative.\r\n\r\n## Npm and semver\r\n\r\nCurrently 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.\r\n\r\nWith 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.\r\n\r\n## Contributor guidelines\r\n\r\nNot of the highest priority right now. Items that could contribute to this are: Code of Conduct, Issue and/or Pull Request templates. \r\n\r\n## i18n\r\n\r\nSpecific technologies would depend on choice of frameworks.\r\n\r\n## Containerization\r\n\r\nDocker. Using multi-stage builds is a good way to containerize the build process while also obtaining a slim deliverable.\r\n\r\n## End to end tests\r\n\r\nSpecific technologies would depend on choice of frameworks\r\n"},"comment":{"url":"https://api.github.com/repos/discipl/core/issues/comments/447903267","html_url":"https://github.com/discipl/core/issues/12#issuecomment-447903267","issue_url":"https://api.github.com/repos/discipl/core/issues/12","id":447903267,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0NzkwMzI2Nw==","user":{"login":"pimotte","id":5917458,"node_id":"MDQ6VXNlcjU5MTc0NTg=","avatar_url":"https://avatars0.githubusercontent.com/u/5917458?v=4","gravatar_id":"","url":"https://api.github.com/users/pimotte","html_url":"https://github.com/pimotte","followers_url":"https://api.github.com/users/pimotte/followers","following_url":"https://api.github.com/users/pimotte/following{/other_user}","gists_url":"https://api.github.com/users/pimotte/gists{/gist_id}","starred_url":"https://api.github.com/users/pimotte/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pimotte/subscriptions","organizations_url":"https://api.github.com/users/pimotte/orgs","repos_url":"https://api.github.com/users/pimotte/repos","events_url":"https://api.github.com/users/pimotte/events{/privacy}","received_events_url":"https://api.github.com/users/pimotte/received_events","type":"User","site_admin":false},"created_at":"2018-12-17T16:18:09Z","updated_at":"2018-12-17T16:18:09Z","author_association":"CONTRIBUTOR","body":"> Via Milo van der Linden:\r\n> \r\n> Read the proposal. It's a solid toolchain proposal in my opinion. The only thing I want to add is: use containers; loosely coupled, Docker file in every repo, well documented. And any frontend should have i18n from the start.\r\n\r\nAdded these to main post along with end to end testing."}}
{"actor":{"display_login":"pimotte"}}