v1.0 - rewrite in npx?

[luarss]

Consider using bun or a fast javascript backend. npx seems like the default preferred distribution for MCP servers.

@kartikloops thoughts?

[kartikloops]

@luarss
From what I’ve seen on our side, we already have a pretty smooth path with uvx (similar idea to npx on the Python side), and the current Python/FastMCP setup is working well for sessions and OpenROAD integration.

I might be missing some of the ecosystem angle though especially around npm/npx being what a lot of MCP examples use. Happy to dig into whatever direction you think makes most sense for v1.0.

[luarss]

I am wondering how to make developer onboarding as seamless as possible. Since majority of mcp servers are on npx, wondering if it is worth the rewrite to shift

[kartikloops]

That makes sense, seamless onboarding is probably the main thing for v1.0.

From what I’ve seen so far, our MCP side is already pretty close to the npx flow via uvx (one command in the client config, no need to clone the repo). The heavier part for new devs still tends to be OpenROAD/ORFS setup rather than the MCP server itself, but I might be underestimating how much friction Python + uv adds for people used to the npx examples everywhere.

I can see the appeal of aligning with how most MCP servers are packaged familiar config, fewer “why is this different?” thoughts in the docs. I’m not sure yet how much a full rewrite would move the needle vs polishing install/docs on the current stack, but happy to help either way.

[luarss]

@kartikloops Can you work on a migration plan and create a branch please? I would like you to scope it out and include the following details.

• Scope of refactor (incremental vs full?)
• Timeline (ideally <3 weeks)
• Schemas
• Packaging
• Testing

If we do decide on migrating - then we should ideally do it at the start of the project, not later.

[kartikloops]

@luarss Sounds good. I’ll put together a migration plan and open a branch for this.

I’ll scope it with the sections you mentioned. I’ll also map the current Python surface area (tools, interactive/PTY layer, config) so we have a clear inventory before deciding incremental vs rewrite.

Agree on timing if we migrate, doing it early in the GSoC window makes more sense than later. I’ll aim to have a first draft of the plan on the branch by end of this week. So we can review and decide before heavy implementation.

I’ll link the branch and plan doc here once it’s up.

[kartikloops]

Draft migration plan is up in docs/MIGRATION_PLAN.md on the branch for review. My current recommendation is stage-gated: validate TS/PTy parity first, and use wrapper fallback if that gate fails.