2026-02-25 Express Working Session

[github-actions]

Date/Time

Timezone	Date/Time
America/Los_Angeles	Wed, Feb 25, 2026, 01:00 PM
America/Denver	Wed, Feb 25, 2026, 02:00 PM
America/Chicago	Wed, Feb 25, 2026, 03:00 PM
America/Bogota	Wed, Feb 25, 2026, 04:00 PM
America/New_York	Wed, Feb 25, 2026, 04:00 PM
UTC	Wed, Feb 25, 2026, 09:00 PM
Europe/London	Wed, Feb 25, 2026, 09:00 PM
Europe/Madrid	Wed, Feb 25, 2026, 10:00 PM
Europe/Paris	Wed, Feb 25, 2026, 10:00 PM
Europe/Warsaw	Wed, Feb 25, 2026, 10:00 PM
Europe/Moscow	Thu, Feb 26, 2026, 12:00 AM
Asia/Kolkata	Thu, Feb 26, 2026, 02:30 AM
Asia/Shanghai	Thu, Feb 26, 2026, 05:00 AM
Asia/Tokyo	Thu, Feb 26, 2026, 06:00 AM
Australia/Sydney	Thu, Feb 26, 2026, 08:00 AM

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=2026-02-25%20Express%20Working%20Session&iso=20260225T2100&p1=1440&ah=1

Agenda

Extracted from top priority labelled issues and pull requests from expressjs/discussions prior to the meeting.

• Use Node.js built-in debug and deprecated utilities instead of relying on external packages. #459
• Propose a higher minimum Node.js version for all the packages (CI related) #236
• docs: update governance document to remove outdated sections #386
• charter: update TC membership guidelines to ensure diverse representation #376
• add Github Access Structure Overview section express#5503

Invited

• @expressjs/express-tc
• @expressjs/triagers
• @expressjs/security-wg

Observers/Guests

This meeting is open for anyone who wants to attend. Reminder to follow our Code of Conduct.

Joining the meeting

• link for participants: https://zoom-lfx.platform.linuxfoundation.org/meeting/95258037175?password=07aad89d-ff43-45df-9b28-f437e167a0b9

---

Please use the following emoji reactions in this post to indicate your
availability.

• 👍 - Attending
• 👎 - Not attending
• 😕 - Not sure yet

[kjugi]

I think agenda was untouched. We have discussed this PR instead: expressjs/express#6404

[bjohansebas]

@kjugi what was discussed about that?

[blakeembrey]

The consensus was that it probably won't land. There's a couple of reasons:

1. This breaks existing users for little benefit (e.g. new URL() currently works).
2. It's an overall change to the design of Express' APIs - if you look at any other method, you'll see they all accept anything and rely on coercion to correct types.

The conversation itself broke down into two classes of issues. The first is whether we should have validation at all, and the majority take was no (we should only validate if it'd otherwise result in an invalid state, not because someone is using the API with something they shouldn't be, the goal of the framework is to be minimal with low overhead), and the second was whether we should be coercing things to make them work (e.g. non-strings into strings) which was more contentious.

The main split of opinion seemed to be on maintainer burden, with the exhaustion on APIs that accept anything making it hard on maintainers, vs breaking existing users who might be using an API successfully with something that we don't expect.