I use TypeScript 2 in my project. I'd like to use some js library, but also typings for that library. I can install types with simple npm install @types/some-library
. I'm not sure if I should --save
or --save-dev
them. It seems to me that even DefinetelyTyped GitHub readme kind of mentions both versions, but never explains them. I would think that @types should be in devDependencies
, as types are needed for development and aren't used in runtime, but I saw many times @types in just dependencies
. I'm confused.
How should I decide whether @types/* goes into dependencies
or devDependencies
? Are there actually some more or less official instructions?
dependencies
and devDependencies
in the latter case.
devDependencies
and dependencies
is irrelevant when building a bundle, it's something that create-react-app
enforces as well but ultimately it's up to you to choose
Let's say you're developing a package "A" that have @types/some-module
package in devDependencies
. For some reason you're exporting the type from @types/some-module
:
import { SomeType } from 'some-module';
export default class APackageClass {
constructor(private config: SomeType) {
// …
}
}
Right now TypeScript consumers of package "A" are unable to guess what SomeType
is, since devDependencies
of package "A" are not installed.
In that particular case you need to place @types/*
package with regular dependencies
. For other cases devDependencies
are good enough.
If you're just generating a bundle there may be no need to make the distinction between dependencies
and devDependencies
. This feature of npm
is generally useful when publishing a package that can be used by others and you don't want to spam them with redundant dependencies.
There may be other use cases where splitting dependencies can be helpful but unless you have an express need for this, then my advice is to just pick either one and place everything there. It's not difficult to split them afterwards if the need should arise.
A well-known example of this practice IRL is create-react-app
, by default the un-ejected boilerplate it creates places everything in dependencies
, see this thread and this answer
devDependencies
are not installed when you do npm install --production
(or npm ci --production
) and thus not available when running production code. This is a very meaningful difference for a service, not just a library.
In the particular case of deploying a Node.js application to production, one wants to install only the dependencies needed to run the application.
npm install --production
or
npm ci --production
or
yarn --production
In that case, the types should be in the devDependencies
, to keep them from bloating the installation.
(To avoid misunderstandings, the --production
option must not be used on machines where the application is built, otherwise the TypeScript compiler will complain.)
Remarks: I'm aware this was mentioned in a comment by Brad Wilson to another answer. This point seems worthy to be an answer, though.
devDependencies
should still exist at that stage, because --production
should only be used when installing for production - not on the developer machine.
--production
option already on machines where the application is built. Instead, the option should be used only on machines where the application is run, not built. I clarified my main answer in that regard.
npm install
on Windows is not correct on Linux.
Other answers made great sense, but I'm gonna add that a peerDep's type declaration package should also be placed in dependencies
instead of peerDependencies
.
Assume that b
is a plugin of a
. And c
uses a
and b
.
Why shouldn't @types/a
be placed in b
's peerDependencies
?
If b
's package.json
is like:
{
"peerDependencies": {
"a": "1.5.x"
"@types/a": "1.4.x"
}
}
c
may use only interfaces defined in @types/a@1.2.x
but c
is forced to install @types/a@1.4.x
.
Furthermore, c
may be a regular javascript package rather than typescript package, but c
is also forced to install @types/a@1.4.x
.
So, the correct package.json
of b
should be like:
{
"peerDependencies": {
"a": "1.5.2"
},
"dependencies": {
"@types/a": "1.4.x"
}
}
Success story sharing
devDependencies
?dependencies
. OtherwisedevDependencies
is finedependencies
will make dependency tree bloated.