Repository navigation
include "typings" field in package.json #2818
Description
Now that the TS compiler supports module resolution via node, it would be nice not to use TSD to install the typing but instead have them included with the npm package.
Now that the TS compiler supports module resolution via node, it would be nice not to use TSD to install the typing but instead have them included with the npm package.
Activity
dougwilson commentedon Nov 30, 2015
We don't have any typings. What would we put in the field?
blakeembrey commentedon Dec 1, 2015
@dougwilson I would be interested in maintaining them, if that sounds reasonable.
Edit: I'll be working on some related type testing tools in https://github.com/typings/typings which will complement any such support for typings.
dougwilson commentedon Dec 1, 2015
@blakeembrey , that is absolutely reasonable! I was just talking about these typings today and I think Express should provide official typings for TypeScript as a feature! This means that we would be invested in properly maintaining them as part of the normal commit and release process. If you want to provide the initial typings for Express, that would be amazing!
Ideally I would love it if we could achieve these things:
These can be independent tasks, but I think Express is going to say yes to supporting TypeScript binding out of the box.
blakeembrey commentedon Dec 1, 2015
Fantastic, I'll work on making sure the CI step is solved properly this week.
rolandjitsu commentedon Dec 2, 2015
@blakeembrey that sounds great 👍 @dougwilson does this mean that typings will also be added to the other expressjs packages (morgan, session, etc.)?
dougwilson commentedon Dec 2, 2015
yes
rolandjitsu commentedon Dec 2, 2015
Great, because I was having a hard time figuring out how to write those typings properly as I kept getting some errors about the way I was declaring them (I was using ambient typings and I realized that is not the way to go).
LinusU commentedon Feb 15, 2016
We actually had this problem come up in multer where the type file that someone used wouldn't account for our middleware adding fields to the
reqobject (namelyreq.file). Is this a problem that could be solved somehow? I think that it affects most middleware...Other than that, we would be happy to include and maintain "typings" for multer as well :)
blakeembrey commentedon Feb 15, 2016
@LinusU Mutations are hard to represent in TypeScript, especially with things like adding a field during middleware execution. It's possible to merge the interfaces and we should do that, if nothing else, but I'm not aware of a way to declaratively merge types depending on possible in middleware. That's something I've been thinking about anyway, but I'm glad to share an example of how this would work.
The reason I haven't yet tried to merge this into Express is because I haven't had time to solve the test suite involved. The closest I have is a feature I've had for a while - bundle the typings, then run the TypeScript compiler, then run unit tests as usual.
jeffbcross commentedon Jun 13, 2016
Would maintainers be interested in converting the express source to TypeScript, so we could automatically generate correct typings with each release? I'd be down for helping with the conversion. // @dougwilson @ritch
dougwilson commentedon Jun 13, 2016
Hi @jeffbcross, thanks for the offer, but there is no plan to convert the source to anything other than pure JavaScript, I'm sorry.
jeffbcross commentedon Jun 13, 2016
Thanks @dougwilson I'm asking about openness to such a thing. I.e. knowing your contributor base, would typescript support be something contributors would want (or at least live with)? I could enumerate the benefits here beyond typings generation if it would be helpful.
dougwilson commentedon Jun 13, 2016
Hi @jeffbcross, I am generally aware of the benefits, but I don't think it aligns with our user base, or even our maintainers. For example, I don't even understand TS and really can't even judge it unless there is a class I can take to learn it? The biggest barrier is that unless the idea is that we transfer ownership of express to you, at the very least the current contributors should know TS well enough to continue to contribute to this module.
I know there is a very minor community that would like TS bindings, mainly for the IDEs, but other than that, I have no real idea how it would impact the user base.
Thoughts? And why would it be necessary to completely change the language this module is written in just to declare type bindings?
10 remaining items
qmnl commentedon Jun 2, 2018
ok sry
wesleytodd commentedon May 31, 2019
In #3972 @commonbreed mentions those typings are out of date. Can you provide some more details here? What is out of date, is there a simple PR we can make to update them?
craben20 commentedon May 31, 2019
@wesleytodd It's likely that the "outdated" types are still accurate, as I don't know whether any signatures have changed from 4.16.1 to 4.17.1. Regardless, it would be nice to have the types package consistent with Express versioning. (Every Express release, make a PR to the types package?)
craben20 commentedon May 31, 2019
Although I think a TS port is more appropriate.
wesleytodd commentedon May 31, 2019
Thanks @commonbreed. Can you explain what you mean by "TS port"?
I see what you mean, and the answer is probably that they are still accurate.
If this is something the typescript community is used to, then we would probably like to support that. That being said, we would need someone from the community who actively uses typescript to step up and maintain them. Is that something you would be interested in?
craben20 commentedon May 31, 2019
Ah, just noticed dougwilson has prohibited porting this code base to TypeScript, which is reasonable in the short term - seems to be what many middlewares are opting for too.
Unfortunately, this is not something the community is used to as such. Types don't tend to be updated until there is a significant code refactor, or until someone reports them as broken. It can be confusing to TypeScript developers when they see npm has pulled an "older" types package. I think it's probably very safe to add DT typing as a dependency (not a devDependency) - this is a library. I'll make a PR now.
craben20 commentedon May 31, 2019
#3973 Here's the PR
wesleytodd commentedon May 31, 2019
Doug is not a dictator. He and the rest of the contributors do not want to port anything to TS. I believe if you search the repo you can find many conversations where we have all shared our opinions on this, so I will not repeat them. But I did not want someone to come along and read this and miss-understand the situation by reading your comment alone.
Ok, I don't won't to add more on that PR discussion yet. But from your comment here it sounds like we do not want to do something which is not already in line with what the TS community expects. If they already are used to installing
@types/expressand the version miss-match is fine as long as the types are still correct, then I would prefer to leave it that way.Again, not getting into the issues in the PR, I disagree that adding DT as a dep here is a good thing. It is not a dep, and since users can opt into typescript and other not, we don't want to make changes which effect everyone for the sake of the few.
craben20 commentedon Jun 7, 2019
I'm fully aware this is a community project and never supposed Doug to be such. Perhaps "prohibited" was a little strong, but the sentiment was to suggest that a TypeScript port is likely not going to be on the table any time soon, so to consider alternative options.
My reason for picking up this issue in the first place was to address specifically Express' lack of typings. Express has over 9M weekly downloads on NPM, and has a large community of middleware developers who might depend on solid, directly maintained types for linting, integration into CI/testing etc.
I mostly concur. Adding this dependency here is probably not the right move. It causes all kinds of issues with versioning and redundancy. I would however urge folks to consider ensuring PRs are at least made to DT's Express types to ensure any API changes are immediately reflected for TS developers. Don't need to make them a dependency - but at least ensure they're up to date. TypeScript is involved in over 30% of projects on NPM, so it's important for types not to get left behind.
wesleytodd commentedon Jun 7, 2019
I was not admonishing you, just making sure the governance model was clear to everyone who might read this in the future :)
I fully agree here. We would love to have someone who has the right knowledge in this area to participate and ensure that we have updated typings. If that person is you, then I would suggest following the repo so you see when update branches are being prepared. Today the matter is just that none of the active core team members (except @blakeembrey who is busy with many other things) are TS users. So we just don't have the person power to make it happen.
applemate commentedon Sep 19, 2021
Roaders commentedon May 1, 2025
It's a shame that such an important project like express still doesn't make Typescript a first class feature. DT is fine... sort of but it's an inconvenient extra step and often the types do not entirely match the actual code. As has been mentioned before the DT types area really only updated after a big refactor or when stuff gets very broken.
I've had many issues over the years with the express DT types. It involves a frustrating trial and error process where you repeatedly install different versions to see what actually works.
This thread is old. Is it still the view of the maintainers that they do not have the knowledge or desire to migrate the package to Typescript? There are many different approaches that can be taken. The simplest would be just to rename all the js files to TS and add a simple extra build step.
I would be very willing to help or to submit a PR that does this initial step. Once the initial step has been completed you can start to make better use of TS features - if you want.
Roaders commentedon May 1, 2025
I see that esm support seems to be lacking as well. as so many people use express as an import part of their node server strategy this is really going to be a barrier to wider esm usage on the node front. Perhaps moving to ESM and to TS could be a goal for express version 6?
bjohansebas commentedon May 1, 2025
Hey @Roaders, there’s no consensus yet on migrating to TypeScript. Follow this issue (expressjs/typescript-wg#1), which I still have pending to create a document that will formalize the TypeScript team. This team will decide whether it would be a good idea to bring the types into the package or not, since if they are integrated, it would become a contract that we would then have to maintain
bjohansebas commentedon May 4, 2025
expressjs/discussions#369