Replace tslint with eslint and prettier

[JamesLefrere]

In the process of having a look through #21 , I thought it would be helpful to be able to retain clean formatting/etc while making changes everywhere. Thankfully, the typescript-eslint packages make this easy to do now, and tslint is being deprecated by its maintainers in favour of this.

The workflow changes just slightly: a typecheck script has been added, because although tslint runs tsc and exits with any errors, eslint is only concerned with code formatting, and doesn't do type checking. This has been added to the monorepo and each package (and Travis, and the readme :)

The other noticeable thing is the spaces before function names; unfortunately, enforcing this rule with prettier isn't possible with the official eslint/prettier, so I hope it's acceptable to lose those.

This PR makes the following changes:

• Add and configure eslint and prettier for the monorepo
• Remove tslint
• Codemod: run yarn lint on the project, which leads to some minor changes (e.g. spaces before function names, which sadly isn't supported by Prettier
• All rules with errors that couldn't be trivially fixed have been disabled; these should be re-enabled gradually
• Add a typecheck script to the monorepo and each package; given that tslint used to do this, and eslint doesn't, it needs to be run separately

Ideally, future PRs can make the typescript linting rules stricter (rather than keep them turned off).

I also tested this with Fether, and it seems fine to me?

Cheers

[parity-cla-bot]

It looks like @JamesLefrere hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement at the following URL: https://cla.parity.io

Once you've signed, please reply to this thread with [clabot:check] to prove it.

Many thanks,

Parity Technologies CLA Bot

[parity-cla-bot]

It looks like @JamesLefrere hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement at the following URL: https://cla.parity.io

Once you've signed, please reply to this thread with [clabot:check] to prove it.

Many thanks,

Parity Technologies CLA Bot

[JamesLefrere]

[clabot:check]

[parity-cla-bot]

It looks like @JamesLefrere signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

[parity-cla-bot]

It looks like @JamesLefrere signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

[amaury1093]

This is very nice work @JamesLefrere, a huge thank you! It's been in a corner of my head to switch to typescript-eslint, since apparently that's the official way TS is going.

There's only one small thing that bugs me: spaces after function names. Is there a way to change .eslintrc to add this rule? In all parity JS/TS projects we have semistandard as the final styleguide (prettier being an optional step before), so I'd like to stick with that in this repo too.

Apart from that, everything lgtm.

[JamesLefrere]

Thanks @amaurymartiny, hope it helps.

Hmm, it seems like it might be quite a pain to keep those extra spaces because of the Prettier team's choice. Here are the possible approaches I can see:

1. Run eslint --fix twice; once with prettier, and then with semistandard rules.

• Pros: this can use an official Prettier version, and it's only one tool to manage.
• Cons: it's slower, a little tricky to manage the config, and there can't be a single .eslintrc that can be used in IDEs, because semistandard and Prettier have conflicting rules that Prettier won't support.

2. Run prettier --write, then eslint --fix without prettier.

• Pros: this can also use an official Prettier version, and a single eslint config would probably work (so this could be used in an IDE)
• Cons: it's also slower, and it's two different steps

3. Use a forked prettier (e.g. prettier-x) with semistandard-based eslint rules.

• Pros: the config should be quite simple, and it's just one tool/stop. It should integrate with an IDE nicely.
• Cons: Forked prettier!

I'd honestly recommend not using standard (also because I'm not quite on board with some of the rules like no trailing commas), but I understand that's not really doable :)

Let me know what you think and I'll go for it.

[amaury1093]

How about just adding a couple of additional rules in .eslintrc (those that make prettier compatible with standard, i.e. spaces, maybe 1-2 others?), would that be possible?

I'd honestly recommend not using standard

Unfortunately we started to stick with semistandard in all parity projects, so that's a hard requirement. Additionally, I don't think prettier is enough, as it's only a formatter, whereas standard also checks code quality rules.

If adding rules in .eslintrc is not possible, then I guess 1 or 2 both seem okay to me too, which is similar to what we did in fether: https://github.com/paritytech/fether/blob/master/scripts/lint-files.sh

[JamesLefrere]

Right, got it. I had another look at this, and it makes more sense to mirror the previous setup a bit more by simply extending the eslint config for standard/semistandard. Easy!

There are just a few deviations with this config and the tslint implementation, but since there were so few errors (under 10), I added some eslint-disables to the affected lines.

Also, eslint helpfully pointed out a minor bug: https://github.com/paritytech/js-libs/pull/227/files#diff-d4e5e510316e79663700052bab19cddcR237

I also took your suggestion and used the same setup for the linting script as Fether 👍

[amaury1093]

Code lgtm! I'll just try to import all these files into Fether, and check that nothing breaks. If so, then I'll merge.

[amaury1093]

Thanks again @JamesLefrere