In package.json, move @types/* from dependencies to devDependencies

[MuleaneEve]

Describe the bug
Currently, engine.io has @types/cookie, @types/cors and @types/node as dependencies. They should instead be devDependencies.

https://github.com/socketio/engine.io/blob/7033c0ed278705b569afef0bfe470c1937d1ec38/package.json#L33-L36

This is causing my projects to take many more packages as dependencies at runtime.

[darrachequesne]

Hi! Please see the rationale there: microsoft/types-publisher#81 (comment)

[MuleaneEve]

My understanding of that comment is that, for @types\x packages, it is ok to put their own (dev)dependencies in dependencies.
I think that's fine because the end-user of these @types\x packages will import them as devDependencies. Therefore, everything that comes along with these packages will also be treated as devDependencies.

As a practical example: The package sharp has a devDependency on @types/node (source code).
So, its @types\sharp includes @types/node as a "regular" dependency (source code).

However, engine.io cannot be imported just as devDependencies. Therefore, all its dependencies become "real" dependencies.

[MuleaneEve]

@darrachequesne Can you please revisit this issue?

[darrachequesne]

Hmm, that's not my understanding:

The short answer would be for module authors - if, as an author, you want to publish your TypeScript package to NPM and the dependencies are in the development section, no one will be able to install it and use it without having to manually install your types dev dependencies.

This was discussed here for the v3 release: #3690

See also: https://stackoverflow.com/a/46011417/5138796

[MuleaneEve]

I see that this topic has been discussed multiple times. Sorry if I still bring it up.

After reading both links, I still don't understand why moving @types/* to devDependencies would prevent end-user projects from compiling: The types would still be available for compilation since dev packages are installed at that point.

Maybe I am missing something...

By the way, when v3 was released, I assume that many other users did succeed in using it (both in dev and in production). So I wonder if the author of that issue had another weird problem that was worked-around by moving the dependencies...

Edit: Also, I have never seen any other npm package that needed to do this. So, I wonder what is unique here.

[darrachequesne]

That's because those types are exposed in the public API of the engine.io package. If you check the build/server.d.ts file in the published package, you will see:

/// <reference types="node" />
import { EventEmitter } from "events";
import { IncomingMessage, Server as HttpServer } from "http";
import { CookieSerializeOptions } from "cookie";
import { CorsOptions } from "cors";

// ...

export interface ServerOptions {
    cookie?: (CookieSerializeOptions & {
        name: string;
    }) | boolean;

    cors?: CorsOptions;
}

So they need to be installed alongside the engine.io package, hence the dependencies. If they were listed as devDependencies instead, the user would need to manually install them:

$ npm install engine.io @types/cookie @types/cors @types/node 

[MuleaneEve]

build/server.d.ts is only relevant when developing and compiling a project. And in these contexts, the devDependencies should be installed. So, if those types are declared as devDependencies by the engine.io package, everything should continue to work.

[MuleaneEve]

I just had an idea: I searched on GitHub, and I found another TypeScript package that depends on cookie:

https://www.npmjs.com/package/@auth0/nextjs-auth0?activeTab=dependencies

In this project, @types/cookie is declared in devDependencies. And it has many .d.ts files that export CookieSerializeOptions:

• https://unpkg.com/browse/@auth0/nextjs-auth0@2.5.0/dist/auth0-session/utils/cookies.d.ts
• https://unpkg.com/browse/@auth0/nextjs-auth0@2.5.0/dist/auth0-session/session/abstract-session.d.ts

Finally, here are some end-user TypeScript projects that use this package and do not explicitly mention @types/cookie:

• https://github.com/adonisv79/entrepos/blob/ec0c1305a6fa7d214f312884dc35cef12be4986d/app/package.json#L12
• https://github.com/sullivanpj/open-system/blob/03aad6db7db2bfcf96b46812e30027e75c6df84d/package.json#L81

---

Edit: More npm packages where @types/cookie is declared in devDependencies:

• https://www.npmjs.com/package/supakit?activeTab=dependencies (exports CookieSerializeOptions)
• https://www.npmjs.com/package/cassava?activeTab=dependencies (exports CookieSerializeOptions)

[MuleaneEve]

@darrachequesne I finally figured out what I was missing: devDependencies are not recursively installed like dependencies. Somehow, I assumed that was the case.

So if we still want to resolve this issue, the only idea I have is to clone CookieSerializeOptions and CorsOptions into engine.io. Then, those types packages will not be needed. But I understand that it would be annoying to keep them in-sync (though, these interfaces change very rarely; see 1 & 2).

What do you think?