search

jeffijoe / typesync

Install missing TypeScript typings for dependencies in your package.json.
MIT License
1.51k stars 21 forks source link

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

Closed karlhorky closed 1 year ago

karlhorky commented 3 years ago

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 commented 3 years ago

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

karlhorky commented 3 years ago

Yep, it is: https://unpkg.com/browse/ky@0.26.0/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 commented 3 years ago

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

karlhorky commented 3 years ago

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

jeffijoe commented 3 years ago

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

jeffijoe commented 3 years ago

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 commented 3 years ago

Yep, that seems like an accurate description 👍

jeffijoe commented 1 year ago

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 commented 1 year ago

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:

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

jeffijoe commented 1 year ago

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.