This contribution guide is not only for core package, also for plugins of grimoire.js maintained by our organization. It is not necessary, but we encourage the other plugins made by third party should use same contribution guide line if possible.
Using slack is the best way to ask main contributors.
Stack overflow is another choice to ask.
Please report them with issues. You can write it in English or Japanese.
If reporter write an issue with Japanese and it is fatal problem of this library,
main contributors would translate them for convenience.
We prepare to translate all of our documents written in Japanese to English. Currently official site and most of documents are written in Japanese, but we will move the main language as English. This is including a lot of stuff to do, we need contributors. Even if you correct our English syntax, we are welcome.
Reducing works we need to do manually is very important.
Please read this guideline for keeping clean repository and keeping developing environment efficiently.
You need to use npm to setup project build environment.(You can use yarn also)
$ git clone <Path to this repository> .
$ npm install
$ npm start
npm start
trigger watch task to rebuild when you changed the codes in src
folder.
This command will change register/index.js
only.
If you want to generate grimoire.js
or grimoirejs-<library-name>.js
to link these script with <script>
tag, you can use env.browser
configuration with the following command.
$ npm start -- --env.browser
If you need to build with all build configurations, you can use npm run build -- --env.prod
to generate all codes.
npm test
will execute unit testing included in test
folder.
If you need to use with the other plugins, npm link
would be useful to use generated new codes.
Several plugins of Grimoire.js are using E2E testing for maintaining same rendering result. If e2e testing are enabled on a repository, the repository should have e2e folder. E2E folder has several folder containing test case to render.
CI would capture screen shot to compare last rendering result. If the compare result was different from last build, CI will send us notification on #e2e
channel in our slack(See official site for more detail).
When the build was triggered with PR, CI would automatically make a comment containing rendering result.
Most of the coding rules are checked with TSLint
. You can run npm run lint
to check whether your code is fitting to coding rule.
Lint task would run on CI also.
But, there are some coding rule not listed in tslint configurations. These rules are listed below.
public publicMethod(): void;
private _privateMethod(): void;
protected __protectedMethod(): void;
Public method name must begin with lower case and should following names are camelCase
.
Private method name must begin with _
, and following characters are same as public method name.
Protected method name must begin with two __
, and following characters are same as public method name.
The version of this package uses semantic-release
.
To generate changelog and release new version automatically, please follow this rule.
chore: COMMIT MESSAGE HERE
fix: COMMIT MESSAGE HERE
feat: COMMIT MESSAGE HERE
But, keeping in mind that we should not break public API.
perf: COMMIT MESSAGE HERE