Open jordigarcl opened 4 years ago
As this project grows and more people wish to contribute, this would be a great way to keep the code clean & readable, and through that, more easily expandable, despite the difficulty of the initial implementation!
Related to #51. I open the PR for discussion before investing more time.
This is a POC to configure
eslint
throughnpm
.eslint
through npm, therefore apackage.json
has been defined.eslint
style guide, that mostly matches the current style. This enforces, among other things, tabs , single-quotes and semicolons.Now
npx eslint .
can be locally run from the root of the project to analyse the code. We can runnpx eslint --fix .
before merging this to solve most formatting issues but didn't include it here not to obfuscate the tool config.Drawback:
Due to the Chrome opaque way of including javascript modules, the analysis reports lots of
no-unused-vars
andno-undef
errors. These could be disabled, but I think that they would provide very useful information for catching variables that break the build. To do so, false positives must be prevented.I suggest to do this by manually including
/* global ... */
and/* exported ... */
header comments in each file to manually disable the check where needed.This would be a major hassle. I believe that once done, maintenance should be easy (run the tool before merging a PR). I did so for AudioManager so you could see what I mean.
I leave it to you guys to discuss!