New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EFI: Publish and maintain types #192
Comments
As far I know currently many people use https://www.npmjs.com/package/@types/express. Do we plan to contribute there or just integrate this into our code base? IMO, anything that we can do to help our community to use Express is a good move, but I don't see a big value as maintainers to rewrite to TS as we already have JSDocs in place (for us and for the community). Also I am not very use to work with TS, so maybe all the plan is smoother than I imagine. |
This comment was marked as outdated.
This comment was marked as outdated.
Is there any advantage of using TS instead of JSDocs? |
We are in a bit of a rock/hard place here. Because of their stance on semver I don't think we can really do either well. Since we are strongly committed to semver support, I almost think it is ideal that we take a hands off approach. That said, if we had folks who were really passionate about it and could make a clear case one way or another I would love it. Mainly because I agree that "anything that we can do to help our community to use Express is a good move".
Yep, this is fundamentally the problem. If we take ownership of them it become our problem. And while I agree we should do what we can to help folks using Express, I think a better way would be to JSDoc things and then let the folks on the TS/DT side generate their types from our JSDoc than to actually ship or build the types our self and deal with their bad decisions around semver. |
As I am thinking about this, maybe the way we could do this "best" is the following:
|
I was going through cleaning up other threads in here and found this one: #7 |
The major advantages I see of sticking to DT instead of inline types are:
|
This shouldn't be an issue for legacy software. Active development would use a local version of TS instead (e.g. bundled with VSCode) even with legacy express apps. |
@fdrobidoux I don't follow. Can you explain what you mean? The issue @ljharb is talking about is that if we publish types along with our packages (instead of relying on DT) we then have to deal with all the version compatibility issues. If we let them handle it, they deal with it. Are you trying to say something else? |
Some extra commentary (some of which already exists here) in #203. |
pillarjs/router#100 I was cleaning up the router issues today and came across these. Do we think we need to decide on this before v5? I am still on the fence. I was going around asking folks if they wanted to work on landing things asap but I don't want to promise this unless we have a clear decision on doing this in repo or with DT. |
My 2 cents on this: TypeScript brings better DX overall; JSDoc does not bring proper types IMO. I'd rather have it on the same package if possible, like Fastify did, but devs already know that Express doesn't ship types anyway. If the TC commits to keeping |
jsdoc checked by TS, with handwritten d.ts files, gives the same quasi-correctness that TS does. |
this is key.
And neither does typescript if that is a thing you care about.
We need a champion for this. If we have that I am no opposed at all to maintaining the types (either in package or in DT, depending on what the champion decides). The problem is we have never had anyone who signed up to do that. And to be clear, I don't mean signing up to re-write it in TS. I would block that or leave the project if there was consensus and I was the only objector. |
Motivation
Types are widely used in the ecosystem, and requested as shown in the Next-10 survey last year. By providing them directly (or helping the community to provide them) would be a good help for the community. But this can be time consuming and not be perfect with versionning (based on typescript)
Expectation
Evaluate if we want to provide more type documentation using TS or JSDoc (or other solution)
Implementation
Status
Part: Technical
Draft
The text was updated successfully, but these errors were encountered: