typesync
typesync copied to clipboard
jeffijoe
Check packages for index.d.ts without `types` or `typings` field in package.json
#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
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)
Could you just check for the existence of index.d.ts on disk (in node_modules)? Or is there an issue with this?
I would prefer not having to check node modules, currently everything works off of the package defs.
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?
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.
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.
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.