Need tslint to be updated in package.json

[PopGoesTheWza]

Using dtslint 0.9.8 for typing unit tests, I get a bunch of rules error in the form:

The 'member-access' rule threw an error in '/xxx/test/types/tests.ts':
TypeError: Cannot read property 'length' of undefined
    at recur (/xxx/node_modules/dtslint/node_modules/tslint/lib/rules/memberAccessRule.js:91:57)
    at visitNodes (/xxx/node_modules/dtslint/node_modules/typescript/lib/typescript.js:17745:30)
    at Object.forEachChild (/xxx/node_modules/dtslint/node_modules/typescript/lib/typescript.js:17985:24)
    at recur (/xxx/node_modules/dtslint/node_modules/tslint/lib/rules/memberAccessRule.js:108:19)
    at visitNode (/xxx/node_modules/dtslint/node_modules/typescript/lib/typescript.js:17736:24)
    at Object.forEachChild (/xxx/node_modules/dtslint/node_modules/typescript/lib/typescript.js:17983:21)
    at recur (/xxx/node_modules/dtslint/node_modules/tslint/lib/rules/memberAccessRule.js:108:19)
    at visitNodes (/xxx/node_modules/dtslint/node_modules/typescript/lib/typescript.js:17745:30)
    at Object.forEachChild (/xxx/node_modules/dtslint/node_modules/typescript/lib/typescript.js:17978:24)
    at walk (/xxx/node_modules/dtslint/node_modules/tslint/lib/rules/memberAccessRule.js:89:15)

• Resorting to --localTs pointing to Typescript 3.6.4 does not help.
• The use of --expectOnly allows the tests to run, but without enforcing any linting rules
• Disabling rules from tslint.json is somewhat more acceptable (though I must disable 11 rules which cannot be enforced (member-access, no-empty-interface, no-unnecessary-class, interface-name, function-constructor, label-position, no-duplicate-variable, no-eval, no-object-literal-type-assertion, radix and prefer-object-spread)

I resorted to (dirtily) patch node_module/dtslint/package.json and upgrade tslint to version 5.20.0... which solved the issue.

1. shouldn't node_module/dtslint/package.json allow tslint to update by specifying ^5.14.0 instead of the current 5.14.0?
2. maybe an option similar to --localTs to specify a local version of tslint is to be used?

[sandersn]

dtslint is primarily for use as Definitely Typed infrastructure (or if you're building a DT-like type repository). If you are writing unit tests for types you should be using tsd instead of dtslint.

Here's where Definitely Typed is:

1. Someday, we'll switch to eslint, so I don't want to spend time on tslint upgrades, or changes of any kind for that matter.
2. dtslint uses all of tslint rules by default, which means that new rules are turned on by default when upgrading. I didn't have time to figure out what set of rules we currently use and switch to using an explicit list. So I locked the version instead.

If you're building a DT-like repository, I would be interested in hearing how your needs are different from DT's. If you're writing unit tests, I'd be interested in hearing what features tsd lacks compared to dtslint.

[PopGoesTheWza]

I wanted to use dtslint over tsd in order to also test rules and not only expectS for my unit testing.
I’ll look into switching from tslint to eslint in my projects.

[PopGoesTheWza]

I noticed a couple unused devDependencies in package.json (@type/mx and @type/parsimmon if I remember correctly)

Do you want me to create a PR which drop these?)

[sandersn]

Interesting, which rules do you want to use? I thought most of them were DT-specific.

I would be happy to see a PR for dropping unused [dev]dependencies.

[PopGoesTheWza]

@sandersn I don't need any specific rule per say. My use case is packages whose source code isn't (and likely never will) in typescript, but ships with handcrafted .d.ts. I see two advantages in having DT rules checked on such .dts

• future contribution will have to stick with DT standards (or at least the enabled rules)
• new contributors are likely to triggers some rules and learn from it (at least I did learn a few things)

Check PR #261 for unused dependencies

[PopGoesTheWza]

@sandersn I'll close this issue for now.

I'll try to get the chance of progressing with the new eslint/typescript settings and plugins.

And maybe I will be able to contribute a PR.

[OliverJAsh]

If you're writing unit tests, I'd be interested in hearing what features tsd lacks compared to dtslint.

The ability to write tests against .ts files: tsdjs/tsd#32