feat: v5 release #1616
feat: v5 release #1616
Conversation
✅ Deploy Preview for expressjscom-preview ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| @@ -0,0 +1,139 @@ | |||
| --- | |||
| title: Express v5 | |||
| tags: site-admin | |||
There was a problem hiding this comment.
Obviously this is the wrong tag, I just copied this from the first post. What tags do we want to use?
There was a problem hiding this comment.
releases? maybe is a good option. Just copying Node
| - `res.send(status)` signature - use `res.sendStatus(status)` | ||
| - `res.sendfile` - use `res.sendFile` instead | ||
|
|
||
| ## Our work is just starting |
There was a problem hiding this comment.
Maybe we can mention the v5.x backlog? expressjs/discussions#266
| As I said above, we did the minimum number of breaking changes we could. I try here to list them in order of impact to application owners, but there are a fair number of subtle | ||
| chnages burried in here which you should read the changelog for more details on. | ||
|
|
||
| ### Goodbye Node.js 0.10, Hello Node 18 and up. |
There was a problem hiding this comment.
| ### Goodbye Node.js 0.10, Hello Node 18 and up. | |
| ### Goodbye Node.js 0.10, Hello Node 18 and Up |
Consistent title casing. Personally, I'd just drop title case and use sentence case.
| author: Wes Todd | ||
| --- | ||
|
|
||
| A lot has happened in the last 10 years, but today we are excited to talk about what has happened in the last 8 months. The Express project has had a renaissance, and we are |
There was a problem hiding this comment.
| A lot has happened in the last 10 years, but today we are excited to talk about what has happened in the last 8 months. The Express project has had a renaissance, and we are | |
| Ten years ago the [Express v5 release PR](https://github.com/expressjs/express/pull/2237) was opened. It is now merged and published! There's a lot to be excited about, but we want to recognize the work of all our contributors, especially Doug Wilson who spent the last 10 years ensuring Express was the most stable project around. Without these contributions this release could not have happened. |
Trying to punch it up a little and avoid starting with "a lot has happened". Also avoid 8 months until next paragraph to keep focus on "released" and congrats. Finally, avoid switching between we/I.
There was a problem hiding this comment.
I also like the idea of an immediate call to action of "Version 5 has been published and you can install it today: npm install express@5!"
Or something like this. Then move on to "The initial PR was opened 10 years ago and there's a lot of be excited about, but the most important thing to mention is the diligent work of all the maintainers and contributors. Special call out to Doug Wilson [...]"
| many contributors over the years, especially @dougwilson who tirelessly maintained one of the most stable projects in the ecosystem over the past 10 years. Without the work from so | ||
| many, this release would not have happened so if you are among these contributors please give yourself a pat on the back. | ||
|
|
||
| So what happened 8 months ago? We went public with a proposed plan to move [Express Forward](https://github.com/expressjs/discussions/issues/160). This plan included re-committing |
There was a problem hiding this comment.
| So what happened 8 months ago? We went public with a proposed plan to move [Express Forward](https://github.com/expressjs/discussions/issues/160). This plan included re-committing | |
| Eight months ago we went public with a plan to move [Express forward](https://github.com/expressjs/discussions/issues/160). This plan included re-committing |
|
|
||
| ## So what about v5? | ||
|
|
||
| Lets start by mentioning how **boring** this release is meant to be. I know this might seem like an odd thing to say, but it was truly our goal to keep this release as simple as we |
There was a problem hiding this comment.
Worried this whole blog post is reading like a speech. Could just read "This release is designed to be boring". Using I vs we again.
This release is designed to be boring. It's a small jumpstart. It has been kept simple to unblock the ecosystem and allow more impactful changes to come in v6 and beyond. Our focus was on dropping old Node.js version support, addressing security concerns, and simplifying maintenance.
| addressing long standing security concerns, and updating the projects process to make things more maintainable for maintainers. To most folks these sound pretty **boring**, but to | ||
| us this means we can more easily ship future feature releases with the more exciting changes. | ||
|
|
||
| Before I move onto the changes for Express users we need to address the timeline and reason we released v5 when we did and on the `next` dist-tag. As part of reviving the project, |
There was a problem hiding this comment.
Very speech like again, we can just kill the first sentence and clarify things quicker and make it easier to skim. Something like:
Version 5 has been release as the
nextdist tag. [...]
Two sentences in a row start with "As part".
| the hook for the security aspects of this. | ||
|
|
||
| *How to migrate:* We recommend using more robust input validation libraries. [There are many on `npm`](https://www.npmjs.com/search?q=validate%20express) depending on your needs. | ||
| Shameless plug from the author, I maintain [a middleware based "code first" OpenAPI library](https://www.npmjs.com/package/@wesleytodd/openapi) for this kind of thing. |
There was a problem hiding this comment.
Let's not plug this if it's a focus on V5 and our contributions, I think this could be a whole other blog post where you focus on validation inputs. Also another first person switch.
There was a problem hiding this comment.
I do not mind first person switchs, it was written by a person lol. That said, I want to give users a clear recommendation, not a wishy wasy "there are options", but since I have never used the other options I cannot vouch for them to make a recommendation. Happy to take a poll of the team and see which ones folks have had success with and recommend a list of them, but I would rather not tell an audience with mixed technical backgrounds "use a validation lib" with no guidance on what that means.
|
|
||
| 1. `:name?` becomes `{:name}`. Usage of `{}` for optional parts of your route means you can now do things like `/base{/:optional}/:required` and what parts are actually optional is | ||
| much more explicit. | ||
| 2. `:name*` becomes `*name`. (@blakeembrey to provide more details) |
| 1. `:name?` becomes `{:name}`. Usage of `{}` for optional parts of your route means you can now do things like `/base{/:optional}/:required` and what parts are actually optional is | ||
| much more explicit. | ||
| 2. `:name*` becomes `*name`. (@blakeembrey to provide more details) | ||
| 3. `:name+` is equivalent to a `*name` and so has been removed |
There was a problem hiding this comment.
Express 4 never supported this.
There was a problem hiding this comment.
pillarjs/router@30b42cb#diff-859f2b16134f796c6f0bb540c54d824024ff05b9722708e13ee78b29476e3471L867
These tests say otherwise?
There was a problem hiding this comment.
Oh! Are you saying this was an artifact of the intermediary PRs?
There was a problem hiding this comment.
The betas, yeah, path-to-regexp has the changes in the README here: https://github.com/pillarjs/path-to-regexp?tab=readme-ov-file#express--4x
| Notice that we use `async/await` and the `getUser` call may throw (user does not exist, db is down, etc), but we still call `next` if it is successful. We dont need to catch the | ||
| error in line anymore if we want to rely on error handling middleware instead because the router will now catch the rejected promise and treat that as calling `next(err)`. | ||
|
|
||
| *editorial note:* Error handling is a huge topic, but one hill I will die on is that errors should be handled as close to the error site as possible. So while this is now handled |
There was a problem hiding this comment.
Remove this, focus on V5 changes.
There was a problem hiding this comment.
I am pretty against examples like the one above without a note that this is a bad practice. But I also want to make sure we dont make an overly complicated example either. Would love to hear others opinions on this kind of thing.
|
Apparently you cannot reply to the review comment directly.
I did this intentionally. The audience for this specifically is broader than developers. It is a post for leaders and folks outside of our typical audience for a technical changelog. I was going to update the changelog itself to be the "punchier" thing. I will send this over to Robin and Jen to get their opinion on this before we make too many changes though, because if that is not hitting then I am totally open to taking a different approach. |
|
|
||
| So what happened 8 months ago? We went public with a proposed plan to move [Express Forward](https://github.com/expressjs/discussions/issues/160). This plan included re-committing | ||
| to the governance we had outlined many years before and added some things to help onboard more contributors to help kickstart progress again. It might not seem important to folks | ||
| who are less involved in Open Source, but project governance is critical to larger projects health. I want to thank the [OpenJS Foundation Cross Project |
There was a problem hiding this comment.
| who are less involved in Open Source, but project governance is critical to larger projects health. I want to thank the [OpenJS Foundation Cross Project | |
| who are less involved in Open Source, but project governance is critical to larger projects health. We want to thank the [OpenJS Foundation Cross Project |
Is this OK to third person?
| So what happened 8 months ago? We went public with a proposed plan to move [Express Forward](https://github.com/expressjs/discussions/issues/160). This plan included re-committing | ||
| to the governance we had outlined many years before and added some things to help onboard more contributors to help kickstart progress again. It might not seem important to folks | ||
| who are less involved in Open Source, but project governance is critical to larger projects health. I want to thank the [OpenJS Foundation Cross Project | ||
| Council](https://github.com/openjs-foundation/cross-project-council/) and it's members for helping us put together this plan. |
There was a problem hiding this comment.
| Council](https://github.com/openjs-foundation/cross-project-council/) and it's members for helping us put together this plan. | |
| Council](https://github.com/openjs-foundation/cross-project-council/) and its members for helping us put together this plan. |
| ## The Breaking Changes | ||
|
|
||
| As I said above, we did the minimum number of breaking changes we could. I try here to list them in order of impact to application owners, but there are a fair number of subtle | ||
| chnages burried in here which you should read the changelog for more details on. |
There was a problem hiding this comment.
| chnages burried in here which you should read the changelog for more details on. | |
| changes burried in here which you should read the changelog for more details on. |
| - `urlencoded` parser now defaults `extended` to false | ||
| - Added brotli support | ||
|
|
||
| ### Removed APIs |
There was a problem hiding this comment.
Since its a blog and probably the interested ones will read it, would it be a good idea to include a reason or link to something so that users can understand why the removed APIs were removed?
| - `req.acceptsLanguage` - use `req.acceptsLanguages` | ||
| - `res.json(obj, status)` signature - use `res.json(status, obj)` | ||
| - `res.jsonp(obj, status)` signature - use `res.jsonp(status, obj)` | ||
| - `res.send(body, status)` signature - use `res.send(status, body)` |
There was a problem hiding this comment.
I think I have a understanding gap here, please help me to understand. Line 129 says,
`res.send(body, status)` signature - use `res.send(status, body)`But line 119 says,
`res.send(status, body)` - use `res.status(status).send(body)`And since res.send(status, body) no longer works, it might be confusing to suggest that? Sames goes for other few methods as I see.
| Node.js version support was holding us back from many critical performance and maintainability changes. Now that we have dropped these versions we have more stable and maintainable | ||
| CI, we can start adopting some newer language and runtime features, and we can drop many dependencies which are no longer required. | ||
|
|
||
| We recognize that this might mean some enterprises have difficulty with older or "parked" applications, and because of this we are working on a partnership with HeroDevs to offer |
There was a problem hiding this comment.
| We recognize that this might mean some enterprises have difficulty with older or "parked" applications, and because of this we are working on a partnership with HeroDevs to offer | |
| We recognize that this might mean some enterprises have difficulty with older or "parked" applications, and because of this we are working on a partnership with [HeroDevs](https://www.herodevs.com/) to offer |
There was a problem hiding this comment.
Could it be better to redirect directly to the page that talks about Express? https://www.herodevs.com/support/express-nes
|
@wesleytodd I volunteer to translate your final post into my native language (Spanish) once it is published if you allow me and consider the translation necessary to generate a greater reach. |
There are still a bunch of TODO's in here, but I need to work on some other stuff so want to push this for now to start getting feedback.