Add functionality for JSHint static analysis tool

[jankrom]

Tool: JSHint

Installed JSHint through npm, which added this to the package.json file. I tested and used the tool by running it on CLI with jshint <path>. JSHint is a static analysis tool that catches suspicious usage that can cause problems in code such as syntax, implicit type conversion, global variable leaking, and more, was designed to be reduce friction of development in javascript.

The following screenshot is from running jshint src/

It does not include all the errors as there are 26249 errors in src folder but gives an idea into what types of errors the tool catches and how it is utilized.

Questions

What types of problems are you hoping your tooling will catch? What types of problems does this particular tool catch?

• It catches suspicious usage that can cause problems in the code. This is things such syntax mistakes, implicit type conversion, leaking global variables, typos, potential bugs
• It helpful for catching JS specific things such as ES5 and ES6 compatibility issues or bugs like == vs ====

What types of customization are possible or necessary?

• Can run as CLI tool or JS module
• Can set custom rules such as environment specific settings, how strict it is, what rules to follow such as allowing or not allowing undefined variables, what code style rules to follow, which errors or files to ignore, can define global variables to decrease false positives

How can/should this tool be integrated into a development process?

• Can be used as an extension in VSCode and also other editors
• Can be setup in CI pipeline
• Can be used in CLI
• Can be included in build tools such as Webpack

Are there many false positives? False negatives? True positive reports about things you don’t care about?

• False positives: when using less conventional style that is still correct and global variables
• False negatives: doesn’t perform deep analysis of code so can not detect program correctness, memory leaks, or how fast it is
• True positives that we don’t care about: it does not have context to things outside of file so sometimes it will say things are not defined when in fact they are, which can lead to a lot of noise in errors and confusion

[coveralls]

Pull Request Test Coverage Report for Build 11491231747

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 82.689%

---

Totals
Change from base Build 11447829284:	0.0%
Covered Lines:	22344
Relevant Lines:	25602

---

💛 - Coveralls

[rosyyang224]

Looks good to me! I like how you noted the maintainers in your json.