How to contribute

Active contributors: ulisesgascon, jonchurch, wesleytodd

Express is a high-traffic, security-sensitive library. Contributions are welcome but go through a deliberate review process. The canonical contributing guide lives at expressjs/.github/CONTRIBUTING.md; this page covers how the workflow plays out specifically inside this repository.

Sub-pages

• Development workflow — branch, commit, and PR flow
• Testing — Mocha, supertest, conventions, fixtures
• Debugging — DEBUG=express:*, common pitfalls
• Patterns and conventions — coding style, error handling, ESLint rules

Where to start

1. Browse open issues labelled good first issue or help wanted.
2. For non-trivial changes (new APIs, behaviour changes), open an issue first to discuss before writing code. The TC reviews larger proposals.
3. Forks should branch off master for bug fixes and small improvements. Larger features may target a future major version branch.

Review expectations

• Tests are required. Every behaviour change needs a test — usually a focused Mocha file under test/.
• Lint is required. npm run lint must pass. CI enforces this in the lint job in .github/workflows/ci.yml.
• CI matrix must pass. Tests run on Node 18–25 across Ubuntu and Windows. Failures on the older Node versions block merges.
• Coverage may not regress. npm run test-ci runs under nyc and uploads to Coveralls.
• History.md is hand-curated. Add a one-line entry under the # Unreleased Changes heading describing the user-visible change.

Definition of done

Item	Required?
Tests passing locally (npm test)	Yes
Lint passing locally (npm run lint)	Yes
CI green	Yes
History.md entry under "Unreleased Changes"	Yes for behaviour changes; optional for internal cleanup
Documentation update	Required if you change a documented API; documentation lives in expressjs/expressjs.com, a separate repo
Type declarations	Not in this repo — @types/express is maintained in DefinitelyTyped

Security issues

Do not file public issues for security vulnerabilities. Use the security policy and the GitHub private vulnerability reporting workflow. Past issues are tracked in History.md (search for "CVE-").

Governance

• The Technical Committee (TC) is the decision-making body. Current TC members are listed in Readme.md.
• Triagers help shepherd issues and PRs; they do not have merge rights by default.
• See expressjs/discussions for the full governance document.

Related pages

• Patterns and conventions for the coding style.
• Testing for how to add new tests.