Ink v3 contains `@types` packages as dependencies

Currently the package.json for v3 contains @types/ packages as dependencies:

https://github.com/vadimdemedes/ink/blob/9ebfe314e865506ccb37b48723a27485346d950b/package.json#L41-L51

These should be listed as devDependencies 😃

[G-Rath]

Sure! It’s primarily for the same reasons that other dependencies are listed as devDependencies: they’re not required by the library at runtime.

In theory none of these packages ever need to be listed as dependencies, but sometimes a library will use types from one or more of the packages in their typed API so those packages are sometimes included as dependencies. In that case, the definitions should usually be included using a looser version, depending on the type in question.

The other way you can do this is like what you’ve done with @types/react: mark the package as optional using peerDependenciesMeta.

Theres pros and cons to these two methods: the first (using dependencies) means that everyone will always get the @types packages that are required for TypeScript users to use your libraries types regardless of if they’re using TypeScript or not; the second (using peerDependenciesMeta) means that the users typically have to manually include the @types/ packages themselves if they’re using TypeScript.

Looking over the codebase, I believe the only @types that should be in dependencies is @types/react-reconciler.

Constraint wise, typically '*' is recommended as mixing type versions can be messy, and it’s usually easier to resolve problems with 1 package than with 2. The type packages are also not always 1:1 with the libraries they’re typing in terms of major versions, so using '*' saves you from having to manage the overhead of doing i.e 24 | 28 | 29 as your constraint, nor will you have to make new releases updating those constraints because a new version of the @types was released & people are getting dependency warnings.

You should also always use '*' as the constraint for @types/node (if it’s in dependencies, which it rarely needs to be), as it’s the one dependency you can’t actually control, and having two versions of it in your dependency tree can lead to some very confusing errors.

Hope that helps clarify things - let me know if you’ve got more questions! 😄

[vadimdemedes]

Landed in 3.0.0-7.