`v2: Add left-hook pre-push

[KKonstantinov]

This is a follow-up to #976 with a goal of improving DX and reducing contributor friction by ensuring linting, formatting, and builds are validated before pushing.

It introduces the following git hooks via Lefthook:

Default Hooks (lefthook.yml)

• Pre-push (runs in parallel):

  • Typecheck (pnpm typecheck:all)
  • Lint (pnpm lint:all)
  • Build (pnpm build:all)
  • Each failed check includes a hint to enable optional pre-commit hooks for earlier feedback

• Post-checkout & Post-merge:

  • Auto-runs pnpm install to keep dependencies in sync

Optional Pre-commit Hooks (lefthook-local.example.yml)

For contributors who prefer earlier feedback, an optional pre-commit configuration is provided:

cp lefthook-local.example.yml lefthook-local.yml

This enables:

• Typecheck (pnpm typecheck:all)
• Lint Fix & Format (pnpm lint:fix:all) with stage_fixed: true

Motivation and Context

PRs could get slowed down by failing CI when there is an accidental omission by the contributor to run lint/typecheck/build before pushing.

Using pre-push as the default (rather than pre-commit) balances catching issues early while not slowing down the commit workflow. Contributors who want faster feedback can opt into the pre-commit hooks.

How Has This Been Tested?

• Tested pre-push hooks: npx lefthook run pre-push
• Tested optional pre-commit hooks by copying lefthook-local.example.yml to lefthook-local.yml

Breaking Changes

No breaking changes, a pure DX improvement.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[chipgpt]

What happens if the test(s) fail? I once had a colleague tell me they don't like putting things like tests in a pre-commit script because you should never stop a developer from committing their code. To be fair, this was in the context of employees working on a commercial software stack, not an open source SDK. Still, it has stuck with me and I think there is something to it.

Example might be if a developer is going out of town for a week and wants to commit their work in progress on a feature. If it is failing a test and can't be committed, then no one else can pick it up while they are out.

[KKonstantinov]

What happens if the test(s) fail? I once had a colleague tell me they don't like putting things like tests in a pre-commit script because you should never stop a developer from committing their code. To be fair, this was in the context of employees working on a commercial software stack, not an open source SDK. Still, it has stuck with me and I think there is something to it.

Example might be if a developer is going out of town for a week and wants to commit their work in progress on a feature. If it is failing a test and can't be committed, then no one else can pick it up while they are out.

They can still do git commit --no-verify and skip the check on-demand - should not be a reason to skip a full step in the checks.

[domdomegg]

Appreciate the PR! Maybe we should discuss this in an in issue/discussion to figure out what we want to agree on?

fwiw my view is that if you want to run things locally you always can, and if not CI will be there to catch this. I've personally found pre-commit/other hooks burn more of my time than they save, or are frustrating when trying to commit a WIP or draft piece of work (appreciate can use --no-verify, but then it's extra stuff to do and doesn't work with GUI git tools, AI agents get confused etc.). Although will flag that I'm not a TypeScript SDK maintainer, and of course there are reasonable differences of opinion here.

[pcarleton]

could we do pre-push by default, and make pre-commit optional?

[KKonstantinov]

could we do pre-push by default, and make pre-commit optional?

This is a great idea and alleviates a lot of the concerns.

Done and pushed.

cc @pcarleton

[KKonstantinov]

Following up on this.

We could observe a lot of PRs having a "prettier fix" commit quite often - this on top of a "test fix" commit.

Having some hooks would resolve that.

[changeset-bot]

⚠️ No Changeset found

Latest commit: ca5bb57

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1003

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1003

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1003

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1003

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1003

commit: ca5bb57