automatically installing the @types package when adding a dependency

[aweary]

reference: https://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

[bnb]

Bonus points if I can just make this the default per-project so it works without thinking about it for my TypeScript projects

Theoretically this could be a config option that can be defined globally in npm itself in addition to being locally defined in an .npmrc. My understanding (I could be wrong) is that all options are like this no matter what.

[bnb]

I wonder if something like --with-defs smartly defaulting to whatever npm perceives as the "default" definitions and --with-defs=<definitions style> (for example, --with-defs=typescript) for explicitly requesting definitions would be a good future proofing approach for a potential future time in which TypeScript is not the primary typing mechanism for JavaScript.

[ljharb]

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.

[merceyz]

I'm pretty sure types should always be dev deps

As long as they aren't used in the public API of the project this is usually the case. Yarn 2 supports this with https://github.com/yarnpkg/berry/tree/master/packages/plugin-typescript where it installs types into devDependencies if the dependency doesn't include its own types, then it's up to the user to move it if needed

[MylesBorins]

This seems like it could be a useful feature, although I do have some slight concerns with "automatically" installing a 3rd party type definition for a module, it seems like it could create an additional attack surface for supply chain attacks.

I could see this being an option that could be included at install time, I believe there are also tools that already exist in the ecosystem to do this behavior.

This feels like something that could be explore via the CLI RFC process, perhaps starting with an issue outlining what this new feature could look like.

https://github.com/npm/rfcs

[dwelle]

Obviously, any additional package adds more risk, but how much likelier will it be that the package in the DT repo will contain malicious code as opposed to the source package itself (which often isn't vetted at all)?

[karlhorky]

Yep, security considerations should be taken seriously, but as @dwelle mentions, there is at least a review process for DefinitelyTyped: https://github.com/definitelytyped/definitelytyped/#make-a-pull-request

@aweary would you create an RFC for this? Would be great to have this built into package managers!

[karlhorky]

Opened an RFC here: npm/rfcs#328

[aweary]

This seems like it could be a useful feature, although I do have some slight concerns with "automatically" installing a 3rd party type definition for a module, it seems like it could create an additional attack surface for supply chain attacks.

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. So it doesn't seem like much of an expanded attack surface vs. what already exists.

[karlhorky]

Opened an RFC for this, since @MylesBorins asked for one to be created: npm/rfcs#328