Tslint rules are barriers to entry

[aghoneim92]

Ever since I started using create-react-app for my Typescript projects, I've noticed that I have to disable quite a few impossible linting rules that make life very hard for a newcomer to this project.

Rules like:

• interface-name
• member-access
• object-literal-sort-keys (wtf?)
• ordered-imports (again, wtf?)

These are rules that are too opinionated in my humble opinion. Furthermore, they are not automatically fixable. Instead, the whole project refuses to compile and shows an overlay on top of the web page. I suggest not using all the 'recommended' rules from the start.

As a hacker who uses your project to quickstart an application, I find that it makes life harder, not easier, in this aspect.

What's even more annoying is that even if you disable the rule you don't like, you have to restart the bundler to see the change in effect.

I understand that these are the official recommended rules from tslint (curated by some kind of pedantic sadomasochist), but there must be a middle ground that we can reach, especially if the user is new to Typescript, to encourage newcomers to use Typescript in their React apps instead of finding it too hard and ditching it altogether.

[aghoneim92]

Opened palantir/tslint#4305 in tslint as well

[ghost]

I think your main point about having a relaxed rule-set is great. I'm using CRA as part of a stack for enterprise applications so I have the experience and time to customize the rule-set to our taste. I find it annoying and distracting, but it's worth it to make sure standards are followed throughout a large code base. But, as you point out, that's not the only use-case here, and indeed one of the main selling points of CRA is that it's "low friction" for new comers. So a relaxed rule set would be spot on for that, and better than disabling TSLint all together.

But, what I want to address is a way of using TSLint that helps with:

[...] if you disable the rule you don't like, you have to restart the bundler to see the change in effect..

I've done the following with "normal" CRA, and using VSCode as my IDE. I'm not 100% sure how it'd work with CRA-TS. I suspect it'd work okay, but I've not tried it so there may be hidden pitfalls. This approach should work with any IDE that uses TSC to provide warnings and errors. VSCode, Atom, Sublime, VS2017, etc. And also any build process that uses TSC, so the rules are applied at build time, as well as development time.

TSLint can be loaded as a TypeScript plugin, which will then provide it's warnings and errors as if they were native TSC warnings and errors.

https://github.com/Microsoft/typescript-tslint-plugin

This plugin requires TypeScript 2.4 or later. It can provide intellisense in both JavaScript and TypeScript files within any editors that uses TypeScript to power their language features.

And as part of that, it'll pick up (most) changes to tslint.json as they happen. I have encountered a couple of cases where I've had to bounce the IDE to pick up the change, though that might just have been my impatience and I didn't wait quite long enough for the change to be detected and acted upon, but they were a tiny minority.

e.g.

I'm working on some code in a .ts file and use console.log("foo"); and TSLint points out no-console! Ugh, I'm deving, I want to use the console!

So I switch to tslint.json, and tweak the config with a snippy comment that vaguely explains the "why":

    // Yes console.
    "no-console": false,

And then, when I switch back to the .ts file I was working in, the error disappears within a few seconds and I can carry on. That greatly reduces the annoyance/distraction factor.

And actually that's given me an idea. A VSCode extension that would let someone right click on a peice of code with a warning/error, and choose "disable TSLint rule" from the context menu. It'd modify the tslint.json and I wouldn't even have to leave the original .ts file! Something to investigate on a slow day maybe.