Comments (9)
Hi! Please see the rationale there: microsoft/types-publisher#81 (comment)
from engine.io.
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.
from engine.io.
@darrachequesne Can you please revisit this issue?
from engine.io.
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: socketio/socket.io#3690
See also: https://stackoverflow.com/a/46011417/5138796
from engine.io.
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.
from engine.io.
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
from engine.io.
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.
from engine.io.
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/[email protected]/dist/auth0-session/utils/cookies.d.ts
- https://unpkg.com/browse/@auth0/[email protected]/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)
from engine.io.
@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?
from engine.io.
Related Issues (20)
- [TS] socket.send / socket.write arguments HOT 1
- Wrong Tag version HOT 2
- Socket instance doesn't wait for all the packets in writeBuffer to be sent before closing the websocket transport. HOT 2
- Downgrade engine_socket transport error "polling request overlap" to 4xx from 5xx HOT 3
- feature: `BaseServer.corsMiddleware` should be publicliy modifiable HOT 3
- data coming from socket io is stopped after 10 minutes when we request call socket io at every 10-10 milisecond backend : node js frontend : angular js HOT 1
- Typescript: engine = undefined HOT 2
- TypeError: Cannot destructure property 'Server' of '_engineIo.default' HOT 5
- Customize response headers with Express middleware HOT 6
- Possible error in websocket code HOT 2
- clientsCount property of server... why need to keep this private, HOT 1
- Log with pino-http middleware raises TypeError: res.on is not a function HOT 1
- Latest uWs not working HOT 5
- ReferenceError: TextDecoder is not defined HOT 5
- Getting unexpected messages from some clients HOT 2
- Node.js versions below 10.2 are not compatible with the latest version 6.5.1. HOT 1
- WebTransport If the length of the data block exceeds maxDatagramSize, the server will be unable to receive the complete message (the client will not send the complete message). HOT 2
- Upgrading from polling to webtransport will report engine invalid WebTransport handshake. HOT 8
- The cache busting t query parameter does not work if multiple connections to the server are made HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from engine.io.