Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RRFC] Detecting and installing Definitely Typed packages #328

Open
karlhorky opened this issue Feb 18, 2021 · 4 comments
Open

[RRFC] Detecting and installing Definitely Typed packages #328

karlhorky opened this issue Feb 18, 2021 · 4 comments

Comments

@karlhorky
Copy link

karlhorky commented Feb 18, 2021

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): RFC: Adding types information to the Package JSON in the registry #126 and Support declaring @types as the supported route for typings dependencies in the package.json microsoft/TypeScript#38249

Prior Art

There are some userland packages which handle this:

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

@Bullfrog1234
Copy link

@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
Copy link

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
Copy link

bnb commented Aug 21, 2021

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants