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

Displaying Firebase data using Angularfire2 5.0 on an Ionic template

Using babel with node.js version 18 allows you to easily import modules with various extensions and run them from the build folder configured with commonJS. Ensure that you have specified "type:module"

What is the significance of the character "^" in versioning within a package.json file?

What could be causing the error "Type 'String' cannot be used as an index type" to appear in my TypeScript code?

Incorporating @mdi/font into Laravel (version 7.2): A step-by-step guide

Encountered an issue while trying to read the property 'temp' of undefined within an HTML document

Encountered an issue when attempting to utilize `npm start` within a React JS project following

What is the best method to remove a value from a JSON object in a CSV file?

Send a variable to the npm command's string parameter (and not to the script executed by the npm command)

What is the reason for using 'Input' as a type instead of referring to it as a value? TS 2749

Exploring the nuances of checking lists in TypeScript

Tips for setting up Azure Maps and installing version 3 of the azure-maps-control package

Having trouble with your npm installation getting stuck on Windows 10 during the fetchMetadata process?

The command 'node' is not identified as an internal or external command, executable program, or batch file

Variety of properties determined by a "type" prop, expanding variations based on a value from the interface

Issue with Angular 8: click event is not triggering when using ngFor directive to iterate through arrays of objects

Browser with Node's https.Agent

"Encountered an error: Expo command not recognized on Mac operating system

Prevent receiving the "deprecated warning for current URL string parser" by enabling the useNewUrlParser option

Can you explain the distinction between "parser" and "parserOptions.parser" in an ESLint configuration?