Consolidate package.json to a single package #797
Conversation
dosubot
bot
added
the
size:L
WalkthroughThis pull request restructures the project's build and dependency management architecture. It consolidates the monorepo from a multi-package structure into a unified build orchestration model at the root level. Package manifest files are removed from individual components, with build scripts migrated to the root configuration using modern tooling (Vite for the client, tsup for SDK and server, tsx for server runtime). The Dockerfile multi-stage build is reshaped to reflect this new structure, and configuration files are updated with dynamic path resolution to support the consolidated layout. Build artifacts are reorganized into centralized dist directories. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
client/vite.config.ts (1)
6-6: Consider using "node:url" for consistency.While
"url"works, prefer"node:url"to match the pattern used inserver/tsup.config.tsandsdk/tsup.config.ts.-import { fileURLToPath } from "url"; +import { fileURLToPath } from "node:url";
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (4)
client/package-lock.jsonis excluded by!**/package-lock.jsonpackage-lock.jsonis excluded by!**/package-lock.jsonsdk/package-lock.jsonis excluded by!**/package-lock.jsonserver/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (9)
Dockerfile(1 hunks)client/package.json(0 hunks)client/src/config/app-config.ts(1 hunks)client/vite.config.ts(3 hunks)package.json(5 hunks)sdk/tsconfig.json(1 hunks)sdk/tsup.config.ts(1 hunks)server/package.json(0 hunks)server/tsup.config.ts(2 hunks)
💤 Files with no reviewable changes (2)
- server/package.json
- client/package.json
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{ts,tsx}: Prefer interfaces for defining object shapes
Constrain generics with appropriate type bounds
Use type guards to narrow unknown or union types before usage
Enforce import ordering consistently
**/*.{ts,tsx}: Prefer named exports in TypeScript modules
Use 2-space indentation
Declare types and interfaces using PascalCase
Files:
client/vite.config.tsclient/src/config/app-config.tsserver/tsup.config.tssdk/tsup.config.ts
client/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (client/CLAUDE.md)
Implement strict TypeScript types: strict prop types, event types, state interfaces, and utility types
In client code, use the @/ alias for imports
Files:
client/src/config/app-config.ts
server/**/*.ts
📄 CodeRabbit inference engine (CLAUDE.md)
server/**/*.ts: Implement robust error handling with safe error messages and log sanitization
Set appropriate security headers for backend responses
Apply rate limiting and backoff strategies to protect APIsUse TypeScript for all backend source files
Files:
server/tsup.config.ts
🧠 Learnings (16)
📓 Common learnings
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-10-19T23:07:40.722Z
Learning: Applies to shared/**/*.{ts,tsx} : Place shared types and utilities in the shared/ directory for reuse by client and server
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: client/CLAUDE.md:0-0
Timestamp: 2025-10-19T23:06:33.450Z
Learning: Applies to client/src/{app,components}/**/*.tsx : Follow React 19 patterns: hooks-centric components, Suspense and Error Boundaries where appropriate, and concurrent features
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-10-19T23:05:54.474Z
Learning: Applies to client/src/**/*.tsx : Follow consistent React component structure in the frontend
📚 Learning: 2025-10-19T23:07:40.722Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-10-19T23:07:40.722Z
Learning: Applies to shared/**/*.{ts,tsx} : Place shared types and utilities in the shared/ directory for reuse by client and server
Applied to files:
sdk/tsconfig.jsonclient/vite.config.tsserver/tsup.config.tssdk/tsup.config.ts
📚 Learning: 2025-10-19T23:07:40.722Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-10-19T23:07:40.722Z
Learning: Applies to src/{main,preload}.ts : Electron entry points are src/main.ts and src/preload.ts
Applied to files:
sdk/tsconfig.jsonserver/tsup.config.tssdk/tsup.config.ts
📚 Learning: 2025-10-19T23:06:33.450Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: client/CLAUDE.md:0-0
Timestamp: 2025-10-19T23:06:33.450Z
Learning: Applies to client/src/**/*.{ts,tsx} : Implement strict TypeScript types: strict prop types, event types, state interfaces, and utility types
Applied to files:
sdk/tsconfig.json
📚 Learning: 2025-10-19T23:07:40.722Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-10-19T23:07:40.722Z
Learning: Applies to client/src/**/*.{ts,tsx} : In client code, use the @/ alias for imports
Applied to files:
sdk/tsconfig.jsonclient/vite.config.tsclient/src/config/app-config.tsserver/tsup.config.ts
📚 Learning: 2025-10-19T23:05:54.474Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-10-19T23:05:54.474Z
Learning: Applies to **/*.{ts,tsx} : Enforce import ordering consistently
Applied to files:
sdk/tsconfig.jsonclient/src/config/app-config.ts
📚 Learning: 2025-10-19T23:07:40.722Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-10-19T23:07:40.722Z
Learning: Applies to server/**/*.{ts} : In server code, use relative import paths
Applied to files:
sdk/tsconfig.jsonclient/vite.config.tsclient/src/config/app-config.tsserver/tsup.config.tssdk/tsup.config.ts
📚 Learning: 2025-10-19T23:06:33.450Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: client/CLAUDE.md:0-0
Timestamp: 2025-10-19T23:06:33.450Z
Learning: Applies to client/src/{stores/servers,lib}/**/*.{ts,tsx} : Persist configuration: local storage, export/import, sync, and backup/restore options
Applied to files:
sdk/tsconfig.jsonclient/vite.config.tsclient/src/config/app-config.tsserver/tsup.config.tssdk/tsup.config.ts
📚 Learning: 2025-10-19T23:07:40.722Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-10-19T23:07:40.722Z
Learning: Applies to {dist,out}/** : Do not edit build artifacts in dist/ or out/
Applied to files:
client/vite.config.ts
📚 Learning: 2025-10-19T23:06:33.450Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: client/CLAUDE.md:0-0
Timestamp: 2025-10-19T23:06:33.450Z
Learning: Applies to client/src/{hooks/mcp,stores/{chat,servers}}/**/*.{ts,tsx} : Synchronize MCP state: track connections, requests, responses, and errors consistently
Applied to files:
package.json
📚 Learning: 2025-10-19T23:07:08.982Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: server/CLAUDE.md:0-0
Timestamp: 2025-10-19T23:07:08.982Z
Learning: Applies to server/index.ts : Use server/index.ts as the server entry point
Applied to files:
package.jsonserver/tsup.config.tssdk/tsup.config.ts
📚 Learning: 2025-10-19T23:06:33.450Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: client/CLAUDE.md:0-0
Timestamp: 2025-10-19T23:06:33.450Z
Learning: Applies to client/src/{app,components}/**/*.tsx : Follow React 19 patterns: hooks-centric components, Suspense and Error Boundaries where appropriate, and concurrent features
Applied to files:
package.json
📚 Learning: 2025-10-19T23:07:08.982Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: server/CLAUDE.md:0-0
Timestamp: 2025-10-19T23:07:08.982Z
Learning: Applies to server/**/*.ts : Use TypeScript for all backend source files
Applied to files:
server/tsup.config.ts
📚 Learning: 2025-10-19T23:07:08.982Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: server/CLAUDE.md:0-0
Timestamp: 2025-10-19T23:07:08.982Z
Learning: Applies to server/utils/transform.ts : Keep data transformation utilities in server/utils/transform.ts
Applied to files:
server/tsup.config.ts
📚 Learning: 2025-10-19T23:07:08.982Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: server/CLAUDE.md:0-0
Timestamp: 2025-10-19T23:07:08.982Z
Learning: Applies to server/routes/llm/openai/**/*.ts : Keep OpenAI integration (client setup, model management, streaming, errors) under server/routes/llm/openai
Applied to files:
server/tsup.config.ts
📚 Learning: 2025-10-19T23:07:08.982Z
Learnt from: CR
Repo: MCPJam/inspector PR: 0
File: server/CLAUDE.md:0-0
Timestamp: 2025-10-19T23:07:08.982Z
Learning: Applies to server/utils/mcp-utils.ts : Put MCP helper utilities in server/utils/mcp-utils.ts
Applied to files:
server/tsup.config.ts
🔍 Remote MCP Context7
Summary of Relevant Context for PR #797 Review
Based on my research, here is the additional context that would help in reviewing this pull request:
Project Context
The MCPJam Inspector is a tool that lets you visually inspect MCP servers and test whether or not you built your MCP server correctly, including testing the server's tools, prompts, and OAuth implementation. The current MCPJam Inspector V1 is built as a modern Next.js application with integrated MCP capabilities using Next.js 15.4 with App Router, React 19, Tailwind CSS 4.x, and the Mastra framework for MCP integration.
Key Dependency Changes
@mcp-ui/client replacement:
mcp-ui brings interactive web components to the Model Context Protocol (MCP), allowing you to deliver rich, dynamic UI resources directly from your MCP server to be rendered by the client. This represents a shift toward richer UI capabilities within the MCP ecosystem compared to the previous @modelcontextprotocol/sdk dependency.
Convex addition:
Convex is the backend platform that keeps your app in sync with everything needed to build full-stack projects, and Convex libraries guarantee that your app always reflects changes to frontend code, backend code, and database state in real time. In Convex, queries are functions written in TypeScript or JavaScript that run directly in the database, allowing the platform to exactly cache data and provide dynamic real-time subscriptions where every query can be subscribed to in real time. This addition suggests the project is moving toward real-time data synchronization capabilities.
Build System Restructuring
The PR represents a significant architectural change from individual package.json files (client/package.json and server/package.json deleted) to a monorepo-style structure with npm --prefix commands. This consolidates dependency management and build orchestration at the root level while maintaining separate configuration files (tsconfig.json, tsup.config.ts) for individual packages.
[::web_search::],
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: prettier-and-build
🔇 Additional comments (11)
client/src/config/app-config.ts (1)
1-1: Path adjustment aligns with monorepo consolidation.The updated import path correctly reflects the migration from individual package.json files to the root-level manifest.
server/tsup.config.ts (1)
5-12: Dynamic path resolution implemented correctly.The computation of
serverDirandrootDirusingfileURLToPathanddirnameis sound, and entry/output paths are properly resolved relative to these anchors. This aligns with the broader monorepo restructure.client/vite.config.ts (3)
8-14: Dynamic path resolution correctly implemented.The
clientDirandrootDircomputation properly anchors all subsequent path resolutions, and settingrootandenvDirensures Vite operates within the correct context.
31-41: Path aliases resolve correctly relative to computed directories.All aliases (
@/shared,@/sdk,@, react modules, and@mcp-ui/client) are properly resolved using the dynamicclientDirvariable, ensuring consistency across the monorepo structure.
97-97: Build output path aligns with centralized artifact structure.Setting
outDirtodist/clientunder the project root matches the Dockerfile expectations and the broader consolidation strategy.Dockerfile (2)
15-16: Workspace-style dependency installation correctly implemented.Using
npm --prefixfor SDK and evals-cli dependencies aligns with the monorepo consolidation and ensures proper isolation during the multi-stage build.Also applies to: 34-34
59-68: Production artifact layout matches new build structure.Copying from
dist/client,dist/server, andsdk/distcorrectly reflects the centralized output directories, and copyingclient/publicto./publicensures static assets are served at the expected paths.sdk/tsup.config.ts (1)
5-15: Dynamic path configuration properly isolates SDK build context.Computing
sdkDirfromimport.meta.urland using it to setcwd,entry,outDir, andtsconfigensures the SDK build operates independently of the caller's working directory. This is essential for monorepo builds.package.json (3)
33-43: Build orchestration streamlined effectively.The consolidated script structure using
tsx,vite, andtsupwith explicit configs correctly implements the unified build pipeline. Thecleananddeps:ciutilities enhance the developer experience.
86-87: Dependencies align with enhanced UI and real-time capabilities.Adding
@mcp-ui/client(5.9.0) for rich web components andconvex(1.26.2) for real-time synchronization reflects the architectural direction described in the PR objectives.Based on previous external tools findings
Also applies to: 104-104
140-140: Zod 4 migration is safe; concerns don't materially apply here.Verification confirms the breaking changes flagged don't affect this codebase:
.default()short-circuiting: No.default()chains exist—concern inapplicable.- Infinity rejection: No Infinity handling in code—concern inapplicable.
.int()safe integers: Used only on therunsfield (test iteration count), which will always be a reasonable positive number well within safe integer bounds—low-risk.- Error handling: Both
instanceof z.ZodErroranderror.messageremain compatible;safeParse().error.errorsalso works.The codebase is ready for Zod 4.1.12 without changes. Note: deprecated APIs like
.passthrough()and.strict()still function but could optionally be modernized toz.looseObject()andz.strictObject()in future refactoring.
| COPY vite.renderer.config.mts ./ | ||
| COPY vite.main.config.ts ./ | ||
| COPY vite.preload.config.ts ./ |
There was a problem hiding this comment.
🧩 Analysis chain
Verify necessity of Electron-specific Vite configs in client build.
The vite.renderer.config.mts, vite.main.config.ts, and vite.preload.config.ts files appear to be Electron-specific configurations. Confirm these are required for the web client Docker build, or if they should be excluded.
🏁 Script executed:
#!/bin/bash
# Description: Check if Electron vite configs are referenced in client build
# Search for references to these configs in client build process
rg -n "vite\.(renderer|main|preload)\.config" client/
# Check the client build script and vite.config.ts
echo "=== Client build command ==="
rg -n "build:client" package.json
echo "=== Client vite.config.ts imports ==="
rg -n "import.*config" client/vite.config.tsLength of output: 359
🏁 Script executed:
#!/bin/bash
# Find and identify the vite config files
fd "vite\.(renderer|main|preload)" .
# Check Dockerfile full context around line 23-25
echo "=== Dockerfile client-builder stage ==="
sed -n '20,35p' Dockerfile
# Verify these configs aren't used in npm run build:client
echo "=== Check if build:client references these ==="
grep -r "renderer\|preload\|main" client/vite.config.ts || echo "No references found"Length of output: 589
Remove Electron-specific vite configs from client-builder stage.
The vite.renderer.config.mts, vite.main.config.ts, and vite.preload.config.ts files are Electron-specific configurations not used by the client build (which only uses client/vite.config.ts). These should be removed from lines 23-25.
🤖 Prompt for AI Agents
In Dockerfile around lines 23 to 25, the Dockerfile copies Electron-specific
Vite configs (vite.renderer.config.mts, vite.main.config.ts,
vite.preload.config.ts) into the client-builder stage even though the client
build only needs client/vite.config.ts; remove the three COPY lines so only
client build assets/configs relevant to the client stage are copied, leaving
client/vite.config.ts untouched and ensuring unnecessary Electron configs are
not included in the client-builder image.
| "emitDeclarationOnly": false, | ||
| "outDir": "./dist", | ||
| "rootDir": "./src", | ||
| "rootDir": "./", |
There was a problem hiding this comment.
🧩 Analysis chain
Verify output structure with rootDir set to "./"
Setting rootDir to "./" while include remains "src/**/*.ts" may cause TypeScript to emit declarations into dist/src/ rather than directly into dist/. Ensure this aligns with the expected artifact structure and with how tsup processes the outputs.
Run this script to verify the SDK build output structure:
🏁 Script executed:
#!/bin/bash
# Description: Check SDK build output structure after compilation
# Build the SDK
npm run build:sdk
# List the dist directory structure
echo "=== SDK dist structure ==="
fd . sdk/dist --type f --max-depth 3
# Check if files are in dist/ or dist/src/
if fd . sdk/dist/src --type f 2>/dev/null | grep -q .; then
echo ""
echo "⚠️ Files found in dist/src/ - may indicate rootDir mismatch"
else
echo ""
echo "✓ Files are directly in dist/ as expected"
fiLength of output: 262
---
🏁 Script executed:
```shell
#!/bin/bash
# Examine the SDK configuration files to understand the build setup
echo "=== sdk/tsconfig.json ==="
cat sdk/tsconfig.json
echo ""
echo "=== sdk/tsup.config.ts ==="
cat sdk/tsup.config.ts
Length of output: 1112
---
🌐 Web query:
```web
tsup dts declaration files output structure rootDir
💡 Result:
Short answer: tsup’s d.ts output follows TypeScript’s emitter rules (it runs tsc for declarations), so the .d.ts files are emitted into tsup’s outDir (dist by default) preserving the input folder structure relative to your tsconfig.json rootDir (or the inferred longest-common-path). To change the output tree for declarations, set rootDir (or outDir) in your tsconfig.json (or adjust your project layout / tsup entry points). tsup’s --dts simply invokes the TypeScript compiler to produce .d.ts for each entry file (one .d.ts per entry by default). [1][2]
References:
- tsup docs: generation of declaration files with --dts (tsup runs the TypeScript compiler for .d.ts). [1]
- TypeScript rootDir behavior and how it controls directory structure of emitted declaration/js files. [2]
Revert rootDir to "./src" to ensure declarations emit directly to dist/
With rootDir set to "./" and include remaining "src/**/*.ts", tsup's declaration generation (which uses TypeScript's emitter) will place .d.ts files into dist/src/ instead of dist/. This mismatch breaks the expected output structure. Restore rootDir to "./src" to align with the actual source location and ensure declarations emit at the root level of dist/.
🤖 Prompt for AI Agents
In sdk/tsconfig.json around line 10, rootDir is set to "./" which causes
TypeScript declarations to be emitted into dist/src/ instead of dist/; change
rootDir back to "./src" so the compiler emits .d.ts files at the root of dist
(matching include: "src/**/*.ts"), then rebuild to verify declarations land in
dist/ rather than dist/src/.
Co-authored-by: Matthew Wang <matt8p@Matthews-MacBook-Pro.local>
No description provided.