dtslint effects yet another error
See original GitHub issueBug Report
I’ve about had enough of dtslint. What was working, this morning, on the notebook I use at home is now not working on the notebook I have at the office - despite dtslint being pinned to a specific version.
It’s effecting this error:
Error: ENOENT: no such file or directory, mkdir '/Users/nicholasjamieson/.dts/perf'
I’m inclined to abandon it in favour of a more straightforward lint-based solution.
I don’t relish reinventing the wheel, but this wheel keeps falling off.
Issue Analytics
- State:
- Created 4 years ago
- Comments:13 (2 by maintainers)
Top Results From Across the Web
dtslint - npm
dtslint tests a TypeScript declaration file for style and correctness. It will install typescript and tslint for you, so this is the only ......
Read more >DefinitelyTyped/DefinitelyTyped - Gitter
Unfortunately it blows up when running npm run lint react with a couple 'Duplicate identifier' errors and a 'Cannot find name' error. Is...
Read more >DefinitelyTyped - Best of JS
This script uses dtslint to run the TypeScript compiler against your dts files. Once you have all your changes ready, use npm run...
Read more >Bending TSLint to your needs - Tim Deschryver
After reading yet another twitter thread asking about the number of RxJS ... After doing this, there was an error because the custom...
Read more >Do not use 'new' for side effects - JSLint Error Explanations
Generally, by constructing an instance you would want to keep that reference, whether to use again later or for "internal" use as part...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

@cartant No it’s not extensible at this point. We added the things that are important to us but are definitely open to see what people need when they want to test their type definitions. Could you open a new issue in tsd directly so we can discuss things? Examples regarding the deprecation signatures and how you think these should be validated would be nice.
We can also look in exposing some kind of plugin system. I will think about how it could look, but I would like to see first if the deprecation checks should be part of tsd itself. Which I feel is perfectly possible to add.
@cartant yes for
expectType, no forexpectError. I wasn’t sure aboutexpectErrorso I asked for feedback about its behaviour https://github.com/SamVerschueren/tsd/issues/10#issuecomment-535686968. So thanks for asking, because it’s valuable feedback if that’s your first question about it 😃.