[RRFC] Detecting and installing Definitely Typed packages

[karlhorky]

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

[Bullfrog1234]

@karlhorky love this idea

In the response to Dev dep or regular dep?

I suggest a second .npmrc setting that sets it to a regular dependency, that way devs that want types as regular dependencies can set it at a package level and npm handles the rest.

Those who don't care (setting not present) will have them placed in the dev dependencies by default.

[yoursunny]

I wish it's possible to install production and development dependencies in one command:

npm i -P react react-dom -D @types/react @types/react-dom

If I know DefinitelyTyped package exist, this would combine two commands into one and save a bit of time, without risking a supply chain attack.

Originally proposed on Dev.

[bnb]

I would prefer that we not bake in TypeScript to the CLI. More specifically, there shouldn't be something that's TypeScript specific in commands or flags - rather, TypeScript should be an option passed to a generic flag:

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

Alternatively, having a different flag that set what "types" were:

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

The latter would have the benefit of allowing you to dump --types=typescript in your global .npmrc so you don't have to include it every time, but when you do run it with something else (for example, --types=flow) that would take precedent.

[Bullfrog1234]

I agree with the proposal to set types flags instead of hard backing in Typescript. If we go down this route it would make managing team repos easier where the flags could be set in .npmrc and essential all future installs would happen as expected with no need to educate new team members of all the install requirements.

[mac2000]

There is one more thing that probably should be covered

In my case, dependency of dependency installed express.js

I do not care about its versions and wish not lock it, but for typescript to work, I need @types/express - and I must lock its version to something 🤔

Ideally, as a consumer, I should not care about all that, and resolving corresponding types packages should happen automatically - e.g. does it makes any sense if i have express v4 and types v5? Version of types should derive from actual installed version to avoid confusions

[hilycker]

Hey hello everybody, "only" 4 years have passed. and this is still under discussion. Any chance reality will light your minds or should we all migrate to other tools? I know the easy answer to me will be "you're free to do so". but this is not the point. Guys, please what in hell is still holding an obvious change given the reality of things? Types are useful for a various number of reasons, it shouldn't really be so tedious to install them in 2025 with the most popular JS package manager. Why it is always so quacking hard to have QoL features? Come on, the frontend world is the opinionated one—it has flooded the internet with software, frameworks, tools, and libraries, all opinionated. Let's not kid ourselves: if something is done a certain way in most cases, there's no point in constantly proposing only generic and open-ended solutions. What really matters is what simplifies and automates the most common tasks. So please, leave the useless justifications to the backend world. And that's coming from a backend developer.