[RRFC] Detecting and installing Definitely Typed packages

Motivation ("The Why")

Originally an issue brought up by @aweary over on npm/feedback:

reference: twitter.com/aweary/status/1353832998723059714

It seems like if npm already knows package-name has type definitions at @types/package-name then I should be able to do npm install package-name --with-ts-defs or something and it will both install package-name and @types/package-name if needed. That way I don't have to wait for TypeScript to tell me that it can't find the definitions. Bonus points if I can just make this the default per-project so it works without thinking about it for my TypeScript projects

I would additionally suggest consideration of an .npmrc setting to globally enable this, similar to what @bnb mentioned.

Example

npm install styled-components --with-types  # would also install @types/styled-components to devDependencies

If there are already types, no secondary package is installed:

npm install emotion --with-types  # no extra packages installed

How

Current Behaviour

Users have to manually search for and install the types on DefinitelyTyped.

Desired Behaviour

If:

• no typings or types fields are specified in the package.json
• no index.d.ts file is in the root
• the package is not written in TypeScript

Then:

• the DefinitelyTyped @types scope is searched for a matching package (see methods below)
• a matching package is installed as a dev dependency

Methods for searching for matching DefinitelyTyped packages:

1. the npm website has this information for the site: https://twitter.com/ethomson/status/1353999139219058688
2. Algolia provides this information over an API, and would be ok with npm using it (but this is a big external dependency): https://twitter.com/haroenv/status/1355563793208795136
3. In the future, the package may have a field for this (thanks for the proposals @orta): https://github.com/npm/rfcs/pull/126 and https://github.com/microsoft/TypeScript/issues/38249

Prior Art

There are some userland packages which handle this:

• types-installer
• typed-install
• install-types

Security Concerns

@MylesBorins brought up security concerns with supply chain attacks:

I do have some slight concerns with "automatically" installing a 3rd party type definition for a module, it could create an additional attack surface for supply chain attacks

However, the behavior of users currently is to already install the matching @types package, as @aweary notes:

TypeScript already recommends installing the @types npm package if it can't find type definitions for a module, so for TypeScript projects people will already be adding those packages manually on the instruction of TypeScript

And also, as I mentioned, there is also a review process for DefinitelyTyped: https://github.com/definitelytyped/definitelytyped/#make-a-pull-request

Dev dep or regular dep?

@ljharb brought up whether the new @types/pkg deps should become dev dependencies (feels like dev deps are the right choice for most cases?)

One concern is, should it be a dev dep or a regular dep? I'm pretty sure types should always be dev deps, but I'm not convinced every part of the community has this convention. Picking "regular dep" could have far-reaching impacts on non-TS users downstream of the current project.

References

• Original npm/feedback discussion: https://github.com/npm/feedback/discussions/174

This is an RFC with no implementation files or tests named. Start with the Desired Behaviour and the linked npm/feedback discussion, then resolve how package.json detection, Definitely Typed lookup, .npmrc configuration, dependency placement, and security concerns should work; done means an agreed design rather than a code change.