What factors should I consider when determining whether to include @types/* in the `dependencies` or `devDependencies` section?

Question

What factors should I consider when determining whether to include @types/* in the `dependencies` or `devDependencies` section?

Currently using TypeScript 2 in my project, I am looking to incorporate a JavaScript library along with its typings. While I know I can easily install the types using npm install @types/some-library, I am uncertain whether to use --save or --save-dev. The DefinitelyTyped GitHub readme vaguely mentions both options without clarification. My instinct tells me that @types should be included in devDependencies, since the types are strictly for development purposes and not utilized during runtime. However, I have noticed @types being placed in dependencies numerous times, adding to my confusion.

How can I determine whether @types/* belongs in dependencies or devDependencies? Are there any formal guidelines available on this matter?

typescript npm typescript-typings package.json

Answer 1

Answer №1

Imagine you're working on a project called "A" which relies on the @types/some-module package in the devDependencies. You decide to export the type from @types/some-module:

import { SomeType } from 'some-module';

export default class APackageClass {
  constructor(private config: SomeType) {
    // …       
  }
}

However, TypeScript consumers of project "A" won't be able to understand what SomeType is without having the devDependencies installed.

In this specific scenario, it's crucial to move the @types/* package to regular dependencies. For other situations, keeping them in devDependencies should suffice.

Answer 2

Imagine you're working on a project called "A" which relies on the @types/some-module package in the devDependencies. You decide to export the type from @types/some-module:

import { SomeType } from 'some-module';

export default class APackageClass {
  constructor(private config: SomeType) {
    // …       
  }
}

However, TypeScript consumers of project "A" won't be able to understand what SomeType is without having the devDependencies installed.

In this specific scenario, it's crucial to move the @types/* package to regular dependencies. For other situations, keeping them in devDependencies should suffice.

Answer 3

Answer №2

If you're in the process of generating a bundle, it may not be necessary to differentiate between dependencies and devDependencies. This functionality within npm is typically more useful when releasing a package for others to use, as it helps avoid overwhelming them with unnecessary dependencies.

While there are scenarios where separating dependencies can be beneficial, unless you have a specific requirement for it, my suggestion would be to simply choose one category and place all dependencies there. If needed, it's easy enough to split them later on.

An example commonly seen in practice is with create-react-app, where the initial boilerplate setup places all dependencies under dependencies by default. You can refer to this discussion thread and this response for more insight.

Answer 4

If you're in the process of generating a bundle, it may not be necessary to differentiate between dependencies and devDependencies. This functionality within npm is typically more useful when releasing a package for others to use, as it helps avoid overwhelming them with unnecessary dependencies.

While there are scenarios where separating dependencies can be beneficial, unless you have a specific requirement for it, my suggestion would be to simply choose one category and place all dependencies there. If needed, it's easy enough to split them later on.

An example commonly seen in practice is with create-react-app, where the initial boilerplate setup places all dependencies under dependencies by default. You can refer to this discussion thread and this response for more insight.

Answer 5

Answer №3

When deploying a Node.js application to production, it is important to only install the necessary dependencies for running the application.

npm install --omit=dev or

npm ci --production or

yarn --production

In order to prevent unnecessary bloat during installation, types should be included in the devDependencies.

(It's worth noting that using the --production or --omit=dev option on machines where the application is built may cause issues with the TypeScript compiler.)

Note: This insight was originally mentioned by Brad Wilson in a comment on another answer, but it deserves its own separate response.

Answer 6

When deploying a Node.js application to production, it is important to only install the necessary dependencies for running the application.

npm install --omit=dev or

npm ci --production or

yarn --production

In order to prevent unnecessary bloat during installation, types should be included in the devDependencies.

(It's worth noting that using the --production or --omit=dev option on machines where the application is built may cause issues with the TypeScript compiler.)

Note: This insight was originally mentioned by Brad Wilson in a comment on another answer, but it deserves its own separate response.

Answer 7

Answer №4

Considering the intended use of your code is crucial. If you plan to incorporate the types into your final product (e.g. when building a custom package that includes these types), they should be included in the dependencies section. However, if the types are only needed during development, it would be more appropriate to include them in the devDependencies section.

Answer 8

Considering the intended use of your code is crucial. If you plan to incorporate the types into your final product (e.g. when building a custom package that includes these types), they should be included in the dependencies section. However, if the types are only needed during development, it would be more appropriate to include them in the devDependencies section.

Answer 9

Answer №5

In addition to the insightful responses provided, it is worth mentioning that a peerDep's type declaration package should be included in the dependencies section rather than the peerDependencies section.

Consider the scenario where b serves as a plugin for a, and c utilizes both a and b.

Why is it not advisable to place @types/a within the peerDependencies of b?

If the package.json file of b looks like this:

{
  "peerDependencies": {
    "a": "1.5.x"
    "@types/a": "1.4.x"
  }
}

c will only use interfaces defined in

@types/<a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="c5a485f4ebf7ebbd">[email protected]</a>

, but it will be required to install

@types/<a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="d8b998e9f6ecf6a0">[email protected]</a>

.

Moreover, even if c is just a regular JavaScript package and not a TypeScript package, it will still need to install

@types/<a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="177657263923396f">[email protected]</a>

unnecessarily.

Hence, the correct structure for the package.json of b should be:

{
  "peerDependencies": {
    "a": "1.5.x"
  },
  "dependencies": {
    "@types/a": "1.4.x"
  }
}

Answer 10

In addition to the insightful responses provided, it is worth mentioning that a peerDep's type declaration package should be included in the dependencies section rather than the peerDependencies section.

Consider the scenario where b serves as a plugin for a, and c utilizes both a and b.

Why is it not advisable to place @types/a within the peerDependencies of b?

If the package.json file of b looks like this:

{
  "peerDependencies": {
    "a": "1.5.x"
    "@types/a": "1.4.x"
  }
}

c will only use interfaces defined in

@types/<a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="c5a485f4ebf7ebbd">[email protected]</a>

, but it will be required to install

@types/<a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="d8b998e9f6ecf6a0">[email protected]</a>

.

Moreover, even if c is just a regular JavaScript package and not a TypeScript package, it will still need to install

@types/<a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="177657263923396f">[email protected]</a>

unnecessarily.

Hence, the correct structure for the package.json of b should be:

{
  "peerDependencies": {
    "a": "1.5.x"
  },
  "dependencies": {
    "@types/a": "1.4.x"
  }
}

What factors should I consider when determining whether to include @types/* in the `dependencies` or `devDependencies` section?

Answer №1

Answer №2

Answer №3

Answer №4

Answer №5

Similar questions

What is preventing type guarding in this particular instance for TypeScript?

Dynamic user input using an enumeration

Encountering an error when attempting to include React TypeScript onChange with a Material UI switch component

Can getters and setters be excluded from code coverage reports in Angular projects?

How can I access members outside of a class without a name in Typescript?

The command 'typings' is not recognizable as an internal or external command, executable program, or batch file

Is it possible to include additional options in the dependencies section of npm package.json file?

How to update a private NPM module from a Git repository and maintain its installation?

Generating a custom node package archive for a lambda function using an npm workspace folder

When Typescript and React Native Imports Clash in an Express App, Resolving the Conflict of "npm run build" Command

I am having difficulty accessing the values stored in my cardTiles variable

I am experiencing difficulties deploying my React app through the npm run deploy command

Retrieve an instance of the property class within a property decorator

Semantic-release failing to generate a new version update for package

Issue: Button ClickEvent is not triggered when the textArea is in onFocus mode

Is there a way to identify the global node dependencies being utilized by my application?

Using [(ngModel)] in Angular does not capture changes made to input values by JavaScript

Strategies for packaging and integrating dependencies within Angular-CLI libraries

How do React Native proxies differ from vanilla React proxies in their functionality?

The 'fullDocument' property is not present in the 'ChangeStreamDropDocument' type