Enhance release flow by adding preversion checks

[alistair3149]

The preversion check runs automatically before npm version. And it will do the following:

1. Lint code
2. Build NPM package
3. Validate server.json
4. Validate manifest.json
5. Build MCP bundle

[Copilot]

Pull request overview

This PR enhances the release workflow by introducing comprehensive preversion validation checks that run automatically before npm version. The validation script ensures code quality, build integrity, and configuration validity before any version bump occurs.

Key changes:

• Adds a new validate-release.cjs script that performs linting, building, and validation checks
• Integrates the validation into npm's preversion lifecycle hook
• Simplifies the GitHub release workflow by consolidating build and lint steps into the preversion check

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

File	Description
scripts/validate-release.cjs	New validation script that orchestrates lint, build, server.json validation, manifest validation, and MCP bundle packing checks
package.json	Adds preversion script hook and new devDependencies (ajv, ajv-formats) for JSON schema validation
package-lock.json	Updates dependency tree to include ajv 8.17.1 and ajv-formats 3.0.1 with their transitive dependencies
.github/workflows/release.yml	Replaces separate build and lint steps with consolidated preversion check for consistency

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[malberts]

This runs locally.

However, should these additional checks not also run as part of normal CI? Or would failure here be due to something upstream, unrelated to our code?

If we need to run these checks as part of normal CI, then this single script is going to make failures a bit less obvious, because the same preversion step will always fail. Not sure if that is a big deal in practice.

[alistair3149]

This runs locally.

However, should these additional checks not also run as part of normal CI? Or would failure here be due to something upstream, unrelated to our code?

If we need to run these checks as part of normal CI, then this single script is going to make failures a bit less obvious, because the same preversion step will always fail. Not sure if that is a big deal in practice.

Yes, it'll cause failure when upstream changes (e.g., one of the JSON schema changes) occur. That's quite common since the MCP standards are moving rapidly with breaking changes.

We can run the script as a part of CI, since we should make sure that the MCP can be built after each code change. Is this the more suitable approach for handling that? Or do you have other suggestions?

[malberts]

I think it's a good idea to run all necessary checks before you get to the release run.

If you change mcpb/manifest.json or server.json, then you'll only know there's an issue later. Although likely you would've checked locally first, but still.

I'm not sure what might typically cause bundle pack to fail, but if a code change can pass all the other checks and still fail there (due to the code change), then we should include that.