Skip to content

Commit c1571be

Browse files
authored
Merge pull request #5 from vlaraort/important-feature
feat: Fix all the ignorance
2 parents b007756 + f9f0a41 commit c1571be

File tree

1 file changed

+60
-0
lines changed

1 file changed

+60
-0
lines changed

intentionality.md

Lines changed: 60 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,60 @@
1+
# Intentionallity
2+
3+
One of the goals of this package is to re-create a full workflow that should be applyied to any big software creation.
4+
5+
This guide is going to be organized by the steps of the development, and explaining every tool used.
6+
7+
## Development
8+
9+
During this phase, the developer codes the features.
10+
11+
### Code Style
12+
* [Eslint](https://eslint.org/): Eslint provides linting capabilities to JS, so every developer should attach to the same code-style rules.
13+
14+
Recommended reading: https://eslint.org/docs/about/
15+
16+
* [eslint-config-airbnb-base](https://www.npmjs.com/package/eslint-config-airbnb-base): This package provides Airbnb's base JS .eslintrc (without React plugins) as an extensible shared config. This base is the "de facto" standard for ES6 linting rules.
17+
18+
* [Prettier](https://github.com/prettier/prettier): Prettier is an opinionated code formatter. It enforces a consistent style by parsing your code and re-printing it with its own rules that take the maximum line length into account, wrapping code when necessary. It adds more power to eslint in the formatting rules.
19+
20+
Recommended reading: https://prettier.io/docs/en/comparison.html
21+
22+
### Testing
23+
24+
There is a test folder with the tests for the library. They has been written using the most regular JS frameworks
25+
26+
* [Mocha](https://mochajs.org/)
27+
28+
* [Chai](http://www.chaijs.com/)
29+
30+
* [Sinon](http://www.chaijs.com/) Is not used in this project, but for complex testing is always needed to test any kind of API calls. It provides stubs, spies and mocks. Their documentation is recommended to know their power, before using it: http://sinonjs.org/
31+
32+
### Code coverage
33+
34+
Represents the percentage of code that has been tested. In this project we use
35+
36+
* [nyc](https://github.com/istanbuljs/nyc): This is the new version of istambuljs, it generates an output of code coverage.
37+
38+
* [codecov](https://codecov.io/): Upload coverage reports, link with github and allow to review the changes on pull requests.
39+
40+
### Build
41+
42+
As the code is written in ES6, it can't be used directly in node, so it has to be transpiled to UMD. In this project we use webpack.
43+
44+
* [webpack](https://webpack.js.org/)
45+
46+
### Version Control
47+
48+
* [Github](https://github.com/): All you know it.
49+
50+
* [Husky](https://github.com/typicode/husky): A tool to add git hooks in client side, totally integrated for JS projects.
51+
52+
### Continous Integration
53+
54+
* [Travis](https://travis-ci.org/): Free CI for open-source projects.
55+
56+
* [semantic-release](https://github.com/semantic-release/semantic-release): Fully automated version management and package publishing. It's a really powerful package. it's used to create Git tags, changelogs, handlying the version number using semver, and enforcing the developers to maintain a sanitized git repository and using commit convention.
57+
58+
### Deployment
59+
* [npm](https://npmjs.org): We use https://registry.npmjs.org/ as a package repository
60+
bower: We also deploy on bower (thanks to git tags generated by semantic-release)

0 commit comments

Comments
 (0)