Code style/formatting rules for TypeScript are not enforced by TSLint

[mturley]

In patternfly-4/react-core, in our tslint.json we extend tslint-config-prettier, but we're not running Prettier when we lint our TypeScript.

From https://www.npmjs.com/package/tslint-config-prettier:

Do you want to use TSLint and Prettier without conflicts? tslint-config-prettier disables all conflicting rules that may cause such problems. Prettier takes care of the formatting whereas tslint takes care of all the other things.

With this configuration, TSLint is no longer enforcing any code formatting / style rules. For code formatting we need to run Prettier, either by using its CLI directly, or by adding tslint-plugin-prettier to our tslint configuration.

I noticed these rules were not being enforced when I reviewed this commit: 6eb1ffd#diff-d2816c60d6fa971b0f62310ff6bef46eR26
Note the lack of indentation in that block.
Here's the CI task that ran tslint on that commit and passed: https://circleci.com/gh/patternfly/patternfly-react/3602

@redallen suggested that maybe we should remove eslint-plugin-prettier from our eslint configuration and use the prettier CLI directly for both eslint and tslint, to get a consistent configuration. This needs more investigation.

[redallen]

Prettier CLI docs: https://prettier.io/docs/en/cli.html

[mturley]

Copying my relevant Slack comments here; we may want to get rid of TSLint and use typescript-eslint instead of fixing the TSLint config. Then we could use eslint-plugin-prettier for both languages.

I wonder if we should consider moving away from tslint entirely in favor of typescript-eslint? Looks like it's going to have better support moving forward, Palantir announced they will be deprecating TSLint, and the core TypeScript team is switching over:
https://eslint.org/blog/2019/01/future-typescript-eslint
https://github.com/typescript-eslint/typescript-eslint#what-about-tslint
It might be nice to publish one recommended linter config for consumers to use no matter whether they are writing JS or TS.
I guess it would need to be a slightly different config for TS to enable the TS parser. But that could extend the JS rules and it would still be simpler to use one linter.
Prettier supports both JS+TS out of the box too so we could include eslint-plugin-prettier without any worry about config differences.

[redallen]

I think for now we should use TSLint on everything, including our JS via the --allowJS option. Later, we can move to ESLint per Palantir's post. I'll investigate the feasibility of TSLint soon™.

[mturley]

@redallen I don't have a strong opinion either way, I just think we should either run Prettier or disable tslint-config-prettier and let TSLint enforce code style (which I'm not sure how well it does, but tslint-config-prettier is disabling some rules)