tslint is outdated

[Maxim-Mazurok]

dtslint uses tslint@5.14.0, while the current version is tslint@6.1.1

It includes, for example, fixes for interfaceName rule: palantir/tslint#4655

Because dtslint uses outdated version, I have to ignore this rule for interfaces such as IPAllocationPolicy

I will try to update tslint in dtslint and open PR.

[sandersn]

The problem with upgrading is that I can't ship with a new tslint without testing it on Definitely Typed. And the set of lint rules on Definitely Typed should not change until we switch to eslint.

Overall, I would prefer to see effort spent on switching to eslint.

[Maxim-Mazurok]

Ok, I'll run tests on DT then to make sure everything passed.

Regarding set of rules, I'll check if any new rules were added or removed. Is updateConfig.ts related to this? If I understand correctly, it can be run on every DT package to check for unnecessary rules. Should I run it, or it's up to DT package maintainers to do this?

I understand that tslint is deprecated and eslint is preferred, but since we're still using tslint and we're not going to use eslint untill DT switched to eslint (if I remember correctly), updating tslint to include fixes seems reasonable.

[Maxim-Mazurok]

Interestingly, running npm test -- --all on DT, even with outdated tslint, gave me a lot of errors.
It's a great opportunity to contribute to DT, but also it means that DT testing can be improved.

[chriskrycho]

@sandersn do you have a roadmap/plan for switching DT and dtslint to ESLint?

Context: I'm digging into a roadmap for more Ember adoption, and part of what we want to build is a story for testing published types both for Ember itself and from the surrounding ecosystem against various versions of TS so that we can satisfy our compatibility story. At present, dtslint is our best option, given that constraint of testing across multiple versions (though I'm also going to be in conversation with tsd about getting that to support this workflow)—but we'd very much prefer not to have both eslint and tslint as dependencies, as you can imagine.

(All of which is in part a long way of saying: I likely have bandwidth to help with the effort; let me know what we need to do to make it happen.)

[sandersn]

Nope, no roadmap yet. Here's a high-level plan of what I think needs to happen.

1. Consult with @uniqueiniquity and @a-tarasyuk who migrated the typescript repo:
   a. How did they catalogue and map built-in tslint rules to eslint rules?
   b. How did they port custom tslint rules to eslint?
2. Catalogue which lint rules we want to map to eslint -- nearly all of them are turned on, but not all are valuable.
   a. Maybe run prettier on all of DT first so that we don't need to port the formatting lint rules (last time @orta and I tried to do it, we were blocked by needing to support TS 2.0, but now DT only supports 3.0 and above).
   b. Turn on the eslint rules we decide to map from tslint.
3. Port rules.
4. Port tslint-based tests.
5. Test on Definitely Typed.
   a. Decide whether failures need a fix in a rule, disabling a rule, or changing package code.
6. Ship updated dtslint.

I think (1), (2) and (3) are all good places to start.

[a-tarasyuk]

7. Port existing tslint.json configs to .eslintrc