tsd demands to have index.d.ts where it is not required

[StreetStrider]

Consider we have package with single module foo.js and definitions in foo.d.ts. We got "main": "foo.js".
If we run tsd on such package, we got:

The type definition `index.d.ts` does not exist. Create one and try again.

However, this file is redundant at such case.

[yss14]

Even with a tsd.directory property set in package.json this error comes up.

[seancroach]

Any progress on this?

Roughly eight months ago I remember having to deal with this rather annoying bug; now I'm having to use this package again and it seems the way I previously got around this does not work.

As of now, tsd is simply unusable in what I'd consider being a realistic configuration due to this false negative throwing an error.

[UselessPickles]

@StreetStrider Does your package.json specify "types": "foo.d.ts"?

My understanding is that tsd looks for the type definitions file specified by package.json, but defaults to looking for index.d.ts.

[StreetStrider]

@UselessPickles that is not exactly my case. package.json types means we're intending to export types. I'm not exporting anything in that particular case. I just have JS module and corresponding d.ts and no index.js at all. If tsd follows TS semantics this should work (because tsc can compile such setup and I have proper tsconfig.json), however it isn't and it points to the redundant nonexistent file. 🤔

[UselessPickles]

@StreetStrider Sounds like this might be a duplicate of (or similar to) #32.

See my comment for a workaround: #32 (comment)

[StreetStrider]

@UselessPickles thanks. That's indeed looks similar. I ended up using dtslint, but it also has its issues (and it is more complex). I solve them similar to your workaround, by creating test subproject with it's own tsconfig which satisfies all limitations. Both systems are not ideal for me and have issues. My use-case is to have expect-typish like tests in my project. I believe, TS projects must have type tests just like they have unit-tests. Having positive and negative type tests is the only way to guarantee your types are correct and that they can be consumed by library user.

[BendingBender]

@SamVerschueren I've tested it out, it seems that it suffices to have a .d.ts file that has the same name as the main entrypoint in package.json, an explicit types field is not required for TypeScript to pick up the definitions. I.e. if the main entrypoint to a package is foo.js then it suffices to have a foo.d.ts for the typings to work correctly.

Do you mind if I implement this logic or do you insist on having an explicit types field in the package.json?

[BendingBender]

@sindresorhus Not sure whether I should start implementing it because I don't know whether this is intended behavior or not. @SamVerschueren doesn't answer, do you have an opinion on this?

[SamVerschueren]

@BendingBender feel free to pick it up! Didn't knew that a typings field was not necessary. Seems like a good one to have 👍.