Skip to content

Read the server version from package.json instead of a second literal - #7

Merged
las7 merged 1 commit into
mainfrom
version-single-source
Aug 22, 2026
Merged

Read the server version from package.json instead of a second literal#7
las7 merged 1 commit into
mainfrom
version-single-source

Conversation

@las7

@las7 las7 commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

serverInfo.version was hardcoded to 0.1.0 in src/server.js:21, while package.json said 0.2.0 and the latest on npm was 0.1.5. Three answers to one question, and the one every client actually saw over the wire was the stale literal, so a client talking to any build since 0.1.1 was told it was 0.1.0.

Reading package.json removes the second place a version can be written, so it cannot drift again. package.json is packed into the tarball regardless of the files list, so it resolves in the published package too. That is asserted below rather than assumed.

Verified

  • 38 tests pass, 1 skipped (the live test, by design)
  • initialize over stdio from the working tree:
    "serverInfo":{"name":"reachpad","version":"0.2.0"}
    
  • and from an extracted npm pack tarball, which is the case that would break if the relative path were wrong:
    from tarball -> version 0.2.0
    

Context

Glama's release flow asks for a version, and it was not possible to answer honestly while the server reported one number, the manifest another, and the registry a third. This does not decide which version to release; it just makes the server tell the truth about whichever one is current.

Worth knowing: package.json is at 0.2.0 and that has never been published. npm's latest is 0.1.5. So after this merge the server will report 0.2.0 while npx @reachpad/mcp still installs 0.1.5 until someone tags v0.2.0. That is normal for an unreleased bump, but it is the reason to cut the release reasonably soon.

🤖 Generated with Claude Code

https://claude.ai/code/session_011jhbZoyzaAjr1MGrSNMWZK

serverInfo.version was hardcoded to 0.1.0 in src/server.js while package.json
said 0.2.0 and the latest on npm was 0.1.5. Three answers to one question, and
the one every client actually saw over the wire was the stale literal: a client
talking to any build since 0.1.1 was told it was 0.1.0.

Reading package.json removes the second place a version can be written, so the
number cannot drift again. package.json is packed into the tarball regardless
of the files list, so this resolves in the published package as well as in the
repo, which is asserted below rather than assumed.

Verified: 38 tests pass; initialize over stdio reports 0.2.0 from the working
tree, and 0.2.0 from an extracted npm pack tarball.

Greentree-Change-Id: 23b6a95844b9dcf42954fa1ffab1b2e4
@las7
las7 merged commit 7e4c73b into main Aug 22, 2026
1 check passed
las7 added a commit that referenced this pull request Aug 22, 2026
Everything since 0.1.6, which is more than a patch: three tool-surface
changes and two defects that made the advertised workflow impossible.

- `create_environment(repo:)` clones into `$HOME/work`. It used to run
  `mkdir -p /work` against a read-only rootfs and fail on every environment
  this server has ever created.
- `expose_port` / `list_ports` / `revoke_port` — an agent can publish what it
  built. The `tcp` channel their absence was blamed on shipped some time ago.
- `pause_environment` — without it, an environment that had run could never
  be archived (`409 lease_held`), so an agent accumulated them until its plan
  limit.
- `get_environment` reports whether an environment is running, and reads the
  head snapshot it always claimed to.
- Names are generated when you do not supply one.

The version now has ONE literal in `src/` (#7) and this commit gives the
other two the same treatment. `server.json` carried it twice more — top level
and `packages[0]` — and nothing compared them to `package.json`, so a release
could publish an npm tarball at one version while telling the MCP registry a
different one: a listing that installs something other than what it
advertises. A test pins all three, and was checked by breaking only the inner
one, which is the half a person reading a diff would miss.

46 pass.


Claude-Session: https://claude.ai/code/session_01HtUyvJQEzLGh7MCzKbiaxx

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant