Allow package to suggest dependency type

[michaelwooley]

There are some packages that should always be peer or dev dependencies. For example, any @types/* repo should be --save-dev.

Perhaps being able to specify this in the package.json (and surfacing this info in npmjs.com) would be helpful.

For example, here:

Additionally, in frameworks like svelte, many but not all dependencies can be dev dependencies. Being clear about this can perhaps avoid some hassle?

This is a spur-of-the-moment thought. Not at all a major pain for me to work this out.

[ljharb]

That is false; there are no packages that are always dev or peer deps. eslint is a peer dep for plugins, but a dev dep for apps, but a prod dep for a wrapper like standard. A DT package like yours is a dev dep, unless it's a runtime or a peer dep of another DT package.

The author simply can never know for sure which category of dependency their consumers will want.

Related: #100.

[Pathum-lakshan]

That is false; there are no packages that are always dev or peer deps. eslint is a peer dep for plugins, but a dev dep for apps, but a prod dep for a wrapper like standard. A DT package like yours is a dev dep, unless it's a runtime or a peer dep of another DT package.

The author simply can never know for sure which category of dependency their consumers will want.

Related: #100.

[KIRAN-KUMAR-K3]

This assertion is inaccurate; the categorization of packages as consistently development (dev) or peer dependencies (peer deps) is not universal. For instance, eslint functions as a peer dependency for plugins, serves as a development dependency for applications, and assumes the role of a production dependency for a wrapper such as 'standard'. In the context of a DefinitelyTyped (DT) package, its classification as a development dependency holds, unless it is specified as a runtime or a peer dependency for another DefinitelyTyped package.

It is crucial to acknowledge that authors cannot definitively predict the preferred dependency category for their consumers. The intricate nature of these dependencies is further discussed in the related issue #100.