Installs typings for packages already providing internal typings

[lucsky]

Example from a test I just did: i18next (https://github.com/i18next/i18next) or (https://github.com/oblador/react-native-keychain).

[jeffijoe]

How do you propose we avoid this? knex has the same problem, it ships it's own typings and also has typings on DT.

[lucsky]

Well, ideally npm or yarn would provide a way to remotely query the targeted package content which would allow to parse the package.json file or look for an existing index.d.ts. But I don't think that's possible so a naive way might be to install those targeted packages outside of the current content, analyse them and only then decide if the can be brought into the package. Would make it more robust but also more slow.

[jeffijoe]

I think it would be safe to assume that packages are already installed when typesync is run, no?

[lucsky]

Uh. Damn. Yeah that's a very good point 😁

[lucsky]

But if not, npm view [NAME OF PACKAGE] types allows to query a package for typings defined in the package.json file. But you're right, it is probably safe to assume that packages are already installed which makes it much more simple.

[jeffijoe]

Alternatively, we can hit the registry ourselves (we already do this to fetch the latest typings info), and it seems the typings field is there! Example: https://registry.npmjs.org/awilix/3.0.0