Linter integration

[liamzebedee]

Closes #42

WIP: code doesn't pass JS/SOL lint checks yet wow that was easier than I thought

[Shadowfiend]

Are the configs not dev dependencies?

[liamzebedee]

Oh woops! Nice catch

[Shadowfiend]

I alllso don't love this, but don't have an immediate fix in mind. Though worth noting, it's usually safer to use sh instead of having to /usr/bin/env bash unless you're relying on bash-specific behavior.

[Shadowfiend]

One thing I missed last time: we do need to align our JS style across Thesis, for simplicity's sake, but that will require moving formatting to prettier, and we'll have to see if we can apply that to Solidity.

The biggest thing to flag is that we're using this prettier config:

semi: false
trailingComma: "all"

Looks like prettier supports Solidity via https://github.com/prettier-solidity/prettier-plugin-solidity, but it's maybe early days yet. I'd be okay with leaving Solidity with its own linter-based formatter initially if we find the prettier plugin is problematic.

[nkuba]

@Shadowfiend what are your thoughts about "Code-quality rules" in context of using prettier?

Code-quality rules: eg no-unused-vars, no-extra-bind, no-implicit-globals, prefer-promise-reject-errors...

Prettier does nothing to help with those kind of rules. They are also the most important ones provided by linters as they are likely to catch real bugs with your code!

Maybe it would be worth using both prettier and linter?

[Shadowfiend]

We should either redo or most likely close this and supersede with eslint alongside eslint-config-keep 0.3.0, which stacks prettier on top of eslint directly.

We can also use prettier-plugin-solidity as in tbtc to handle solidity as well.

[nkuba]

Closing in favour of #328