Check packages for index.d.ts without types or typings field in package.json

[karlhorky]

#24 implemented checks for internal types in packages, but it seems like it didn't address the case of a package with an index.d.ts but no types / typings field in package.json.

This is apparently allowed, according to TypeScript docs (and also used in the wild):

https://twitter.com/sindresorhus/status/1342368373296881664

[jeffijoe]

Is that file included in the files array of the package?

[karlhorky]

Yep, it is: https://unpkg.com/browse/[email protected]/package.json

Is the files key also considered?

I guess this would work in most cases! Wonder if there are any cases in which this would fail (eg. no files key, or a files key with a wildcard, etc)

[jeffijoe]

I suppose a check for any *.d.ts will do in the files array.

[karlhorky]

Could you just check for the existence of index.d.ts on disk (in node_modules)? Or is there an issue with this?

[jeffijoe]

I would prefer not having to check node modules, currently everything works off of the package defs.

[jeffijoe]

Just so I understand the issue, you want the presence of index.d.ts in the files array to prevent the lookup of a @types/ variant, similar to the presence of a typings field?

[karlhorky]

Yep, that seems like an accurate description 👍

[jeffijoe]

It seems even the NPM API doesn't return the files array either. So I think this is better solved by making packages specify their typings correctly in the package using types or typings.

[karlhorky]

Files on disk would be an alternative.

Also, there are other ways of doing it - eg. relying on a single request (either GET or HEAD) to the popular, performant CDN UNPKG:

• File exists (200-level response code): https://unpkg.com/[email protected]/index.d.ts
• File doesn't exist (404 response code): https://unpkg.com/[email protected]/not-there

I think it's a popular enough pattern in npm package publishing to put in some work to try to support it.

[jeffijoe]

Files on disk would not be deterministic, as there would be a difference between running typesync before or after an npm install

Using unpkg is an idea, but considering how I just got burned from using 2 different sources, I would rather stick to what npm returns.

ky now includes the types field, by the way.