Release 4.18.3

[UlisesGascon]

This is a tracking issue for release 4.18.3

Please keep feature requests in their own issues

If you want to make a comment on a particular change, please make the comment in the "Files changed" tab so comments are not lost during a rebase.

List of changes for release:

• Fix routing requests without method
• deps: [email protected]
  • Fix strict json error message on Node.js 19+
  • deps: content-type@~1.0.5
  • deps: [email protected]

Testing this release

If you want to try out this release, you can install it with the following commands:

$ npm cache clean express
$ npm install expressjs/express#4.18.3-staging

Owners/collaborators: please do not merge this PR :)

[UlisesGascon]

As most of the changes are already in master it is quite hard to see the changes in this PR, but here is a list compared to 4.18.2:

• Use https: protocol instead of deprecated git: protocol by @vcsjones in Use https: protocol instead of deprecated git: protocol #5032
• build: [email protected] and [email protected] by @abenhamdine in build: [email protected] and [email protected] #5034
• ci: update actions/checkout to v3 by @armujahid in ci: update actions/checkout to v3 #5027
• test: remove unused function arguments in params by @raksbisht in test: remove unused function arguments in params #5124
• Remove unused originalIndex from acceptParams by @raksbisht in Remove unused originalIndex from acceptParams #5119
• Fixed typos by @raksbisht in Fixed typos #5117
• examples: remove unused params by @raksbisht in examples: remove unused params #5113
• fix: parameter str is not described in JSDoc by @raksbisht in fix: parameter str is not described in JSDoc #5130
• fix: typos in History.md by @raksbisht in fix: typos in History.md #5131
• build : add [email protected] by @abenhamdine in build : add [email protected] #5028
• test: remove unused function arguments in params by @raksbisht in test: remove unused function arguments in params #5137
• use random port in test so it won't fail on already listening by @rluvaton in use random port in test so it won't fail on already listening #5162
• tests: use cb() instead of done() by @kristof-low in tests: use cb() instead of done() #5233
• examples: remove multipart example by @riddlew in examples: remove multipart example #5195
• Update support Node.js@18 in the CI by @UlisesGascon in Update support Node.js@18 in the CI  #5490
• Fix favicon-related bug in cookie-sessions example by @DmytroKondrashov in Fix favicon-related bug in cookie-sessions example #5414

[rluvaton]

Hey @UlisesGascon I didn't realize you are contributing to express as well, I thought I got node release notification 😆

[wesleytodd]

As this is the first release prep we are doing with the new TC members, I just wanted to comment and thank @UlisesGascon for sorting this all out!

In the future we will update the documentation for this process to make sure it is approachable, but for now we were working on ensuring it followed the process as best we could. If anyone sees something we missed (cc @dougwilson) please let us know here.

[jonchurch]

Here's the Compare view link if you want an autoupdating and clean diff/commit list: 4.18.2...4.18.3-staging

[jonchurch]

@UlisesGascon if you still want to block merging on this until it is ready, can I suggest converting it to a draft or leaving a blocking comment as a review yourself with what is still to be done? I missed your comment of

Owners/collaborators: please do not merge this PR :)

so was wondering why it wasn't merged if it's approved. Im not able to merge, so not risk there to me specifically. This is a process nit, but I suggest using the tools we have natively in github to communicate readiness of PRs.

This is for bus factor, async collaboration reasons, and legibility. Someone can always log on at 3am and click merge bc everything is green. No harm here if that's done, but let's not make it that easy for folks to do the opposite of what you've asked! An owner can always switch it from draft to published, and merge anyways, but that's a lot harder to do by accident.

[wesleytodd]

Yeah I agree with @jonchurch long term. What @UlisesGascon and I chatted about in slack was more about "lets try and replicate exactly what Doug would do in the past", hence attempting to follow the full form. The previous example is here:

#4287

[jonchurch]

Ah! I missed that context, understood ❤️❤️

[sheplu]

Amazing work!
I may be missing something but where is it published ? I am not seeing in on the npm express page

It could be interesting to have a quick chat with the team behind sails / nestjs / nextjs (?) and other big framework that rely on express, just to check with them if they can run their test against this version

[UlisesGascon]

I may be missing something but where is it published ?

If we are happy with the changes in this PRs (2-3 active TC members approval?), I will merge the PR and then generate the tag, release and finally publish it on NPM 👍.

It could be interesting to have a quick chat with the team behind sails / nestjs / nextjs (?) and other big framework that rely on express, just to check with them if they can run their test against this version

Agree, but not sure if we have already all the comms in place with them. Also this won't be a breaking change, so I assume that we can release it without waiting. But definitively we will need to have it in the future.

[sheplu]

LGTM

[wesleytodd]

I think ideally we smooth these things out as we move forward and this lands pretty much as is. So I think my proposal is that we take these conversations into the discussions repo so we can improve the process in the future and we just land this. I was going to try and test it in a project or two today, but this is low risk and so I wouldn't want little things to block it.

[UlisesGascon]

I will do the release tomorrow on Feb 29th unless there is any blocker or change request before that 🙂

[UlisesGascon]

Release has been completed!

• https://github.com/expressjs/express/releases/tag/4.18.3
• https://www.npmjs.com/package/express/v/4.18.3