chore(deps): Migrate from npm to pnpm with workspace support#1275
chore(deps): Migrate from npm to pnpm with workspace support#1275
Conversation
Replace npm with pnpm as the package manager and set up pnpm workspaces to centralize dependency management across all sub-packages. Changes: - Add pnpm-workspace.yaml with browser, scripts/memory, website/client, website/server as workspace packages - Replace all package-lock.json files with a single pnpm-lock.yaml - Update .tool-versions: npm → pnpm - Add packageManager field to package.json - Update all CI workflows to use pnpm/action-setup and pnpm commands - Update root Dockerfile to use pnpm - Update website server Dockerfile to build from repo root context with workspace dependency resolution - Update website client Dockerfile and compose files for pnpm - Change workspace dependencies: - scripts/memory: file:../.. → workspace:* - website/server: github:yamadashy/repomix#main → workspace:* - Simplify CI jobs: remove npm link dance, use pnpm --filter instead Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Rename browser package from "repomix" to "repomix-browser" to avoid workspace name collision with root package - Fix cloud-deploy script to submit repo root as build context - Use corepack enable consistently in all Dockerfiles instead of hardcoding pnpm version (reduces maintenance when version bumps) - Replace npm link with pnpm link --global in root Dockerfile - Change prepack script from "npm run build" to "node --run build" - Replace "npm run" with "pnpm run" in sub-package scripts (browser, website/client, website/server) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThis PR performs a comprehensive migration from npm to pnpm across the entire project, including GitHub Actions workflows, Docker configurations, workspace setup, and package.json files. It replaces npm commands with pnpm equivalents and adds a pnpm workspace configuration. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly refactors the project's dependency management system by transitioning from npm to pnpm and establishing a monorepo structure using pnpm workspaces. This change aims to improve build performance, reduce disk space usage, and streamline dependency resolution across all sub-packages. The migration also simplifies CI/CD pipelines and updates Docker configurations to align with the new package management approach, enhancing overall development efficiency and consistency. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
⚡ Performance Benchmark
Details
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request successfully migrates the project from npm to pnpm, introducing pnpm workspaces for better monorepo management. The changes are comprehensive, updating package scripts, CI workflows, and Docker configurations to align with the new setup. The use of corepack, pnpm --filter, and the workspace:* protocol are all correctly implemented. The Dockerfiles have been thoughtfully updated to support workspace-aware builds, especially the multi-stage build for the server.
I have one suggestion regarding the Docker Compose configuration for development to improve clarity and maintainability. Otherwise, this is a great improvement for the project's dependency management and build process.
website/compose.yml
Outdated
| context: ./client | ||
| dockerfile: Dockerfile |
There was a problem hiding this comment.
Configuring the server service to use the client's build context and Dockerfile is confusing and could lead to maintenance issues. It makes it seem like the server's build is dependent on the client's files. Since both services use the same generic base image for development, a clearer approach would be to use a dedicated, neutrally-located Dockerfile. For example, moving website/client/Dockerfile to website/Dockerfile.dev and updating both client and server services to use it would make the configuration more intuitive and decoupled.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
website/server/cloudbuild.yaml (1)
15-15: Root.dockerignoreis comprehensive but could be more explicit about excluding workspace Dockerfiles.The root
.dockerignoreexists and covers most cases (node_modules, .git, .env.*, *.md, .vscode, coverage, dist, build). However, when building with context., it doesn't explicitly exclude Dockerfile and cloudbuild.yaml files from workspace subdirectories (e.g.,website/server/Dockerfile,website/server/cloudbuild.yaml,website/client/Dockerfile). Adding these to the root.dockerignorewould reduce build context bloat without affecting functionality:Dockerfile cloudbuild.yaml cloudbuild.yml .dockerignoreThis prevents unnecessary inclusion of non-runtime container build artifacts in the uploaded context.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@website/server/cloudbuild.yaml` at line 15, Update the root .dockerignore to explicitly exclude workspace Dockerfiles and Cloud Build manifests to shrink build context: add entries for Dockerfile, cloudbuild.yaml, cloudbuild.yml and .dockerignore (so files like website/server/Dockerfile, website/server/cloudbuild.yaml, website/client/Dockerfile are ignored when building with context '.'); modify the root .dockerignore file to include those patterns alongside the existing ignores..github/workflows/npm-publish.yml (1)
28-33: Add pnpm cache configuration to setup-node.Other workflows in this PR (autofix.yml, benchmark.yml) include
cache: pnpmin theactions/setup-nodestep, but this workflow is missing it. This omission may cause slower CI runs due to repeated dependency downloads.♻️ Proposed fix to add cache configuration
- name: Setup Node.js uses: actions/setup-node@53b83947a5a98c8d113130e565377fae1a50d02f # v6.3.0 with: node-version-file: .tool-versions registry-url: 'https://registry.npmjs.org' + cache: pnpm🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/npm-publish.yml around lines 28 - 33, The setup-node step using actions/setup-node@53b83947a5a98c8d113130e565377fae1a50d02f is missing pnpm caching; update that step (the block with node-version-file: .tool-versions and registry-url: 'https://registry.npmjs.org') to include cache: pnpm so dependencies are cached between runs and CI is faster.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/npm-publish.yml:
- Line 60: The workflow uses the pnpm publish command with the --no-git-checks
flag which bypasses pnpm's safety check; either remove --no-git-checks from the
run: pnpm publish --provenance --access public --dry-run to restore git
cleanliness verification, or if intentional, add an inline comment in the
workflow explaining why --no-git-checks is required and ensure the same
change/comment is applied to the other occurrence (the run line at the second
occurrence noted in the review).
In `@package.json`:
- Line 22: The prepack script currently uses "prepack" with "node --run build"
which requires Node 22+, but the package.json "engines.node" allows Node 20;
update one of them so the declared engine range matches the script: either
change the "prepack" script to a Node-20-compatible command (for example invoke
the build via "npm run build" or another shell-safe build invocation) or raise
"engines.node" to >=22.0.0; touch the "prepack" entry and/or the "engines.node"
value in package.json (referencing the prepack script name "prepack" and the
engines field "engines.node") so they are consistent.
In `@website/compose.yml`:
- Around line 18-21: The server service in the compose file is using the wrong
build context; update the server build block so context points to the repository
root (e.g., context: ..) and the dockerfile points to the server Dockerfile
(dockerfile: website/server/Dockerfile) to match how compose.bundle.yml
configures the server; modify the server build configuration (service name:
server, keys: context and dockerfile) accordingly so the files copied in
website/server/Dockerfile (pnpm-lock.yaml, pnpm-workspace.yaml, .npmrc) are
available during docker build.
---
Nitpick comments:
In @.github/workflows/npm-publish.yml:
- Around line 28-33: The setup-node step using
actions/setup-node@53b83947a5a98c8d113130e565377fae1a50d02f is missing pnpm
caching; update that step (the block with node-version-file: .tool-versions and
registry-url: 'https://registry.npmjs.org') to include cache: pnpm so
dependencies are cached between runs and CI is faster.
In `@website/server/cloudbuild.yaml`:
- Line 15: Update the root .dockerignore to explicitly exclude workspace
Dockerfiles and Cloud Build manifests to shrink build context: add entries for
Dockerfile, cloudbuild.yaml, cloudbuild.yml and .dockerignore (so files like
website/server/Dockerfile, website/server/cloudbuild.yaml,
website/client/Dockerfile are ignored when building with context '.'); modify
the root .dockerignore file to include those patterns alongside the existing
ignores.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 4a9cd5c7-c39f-4eed-9145-f3496b2a062a
⛔ Files ignored due to path filters (6)
browser/package-lock.jsonis excluded by!**/package-lock.jsonpackage-lock.jsonis excluded by!**/package-lock.jsonpnpm-lock.yamlis excluded by!**/pnpm-lock.yamlscripts/memory/package-lock.jsonis excluded by!**/package-lock.jsonwebsite/client/package-lock.jsonis excluded by!**/package-lock.jsonwebsite/server/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (20)
.github/workflows/autofix.yml.github/workflows/benchmark.yml.github/workflows/ci.yml.github/workflows/npm-publish.yml.github/workflows/perf-benchmark.yml.github/workflows/schema-update.yml.gitignore.tool-versionsDockerfilebrowser/package.jsonpackage.jsonpnpm-workspace.yamlscripts/memory/package.jsonwebsite/client/Dockerfilewebsite/client/package.jsonwebsite/compose.bundle.ymlwebsite/compose.ymlwebsite/server/Dockerfilewebsite/server/cloudbuild.yamlwebsite/server/package.json
| - name: Publish (dry-run) | ||
| if: ${{ inputs.dry-run }} | ||
| run: npm publish --provenance --access public --dry-run | ||
| run: pnpm publish --provenance --access public --dry-run --no-git-checks |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does pnpm publish support --provenance flag for npm registry?
💡 Result:
Yes, pnpm publish supports the --provenance flag for the npm registry. pnpm passes unknown flags, including --provenance, through to the underlying npm CLI during publishing. This feature was explicitly added via a merged pull request in 2023 (PR #6436), and users have reported successful usage, such as in GitHub Actions workflows and issue resolutions where it works after ensuring a compatible npm version. Official pnpm documentation does not list --provenance as it focuses on pnpm-specific options, but npm docs confirm --provenance generates provenance statements when publishing from supported CI/CD environments like GitHub Actions ubuntu-latest runners. Alternatives like NPM_CONFIG_PROVENANCE=true or "publishConfig": {"provenance": true} in package.json also enable it without the flag.
Citations:
- 1: feat: support
publish --provenancepnpm/pnpm#6436 - 2: Support
pnpm publish --provenancepnpm/pnpm#6435 - 3: Pnpm publish with provenance flag doesn't work pnpm/pnpm#6607
- 4: https://pnpm.io/cli/publish
- 5: https://docs.npmjs.com/generating-provenance-statements/
Ensure --no-git-checks is intentional.
The --no-git-checks flag disables pnpm's verification that the working directory is clean and HEAD matches a git tag. Confirm this is deliberate given it removes a safety check.
Also applies to: 64-64
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/npm-publish.yml at line 60, The workflow uses the pnpm
publish command with the --no-git-checks flag which bypasses pnpm's safety
check; either remove --no-git-checks from the run: pnpm publish --provenance
--access public --dry-run to restore git cleanliness verification, or if
intentional, add an inline comment in the workflow explaining why
--no-git-checks is required and ensure the same change/comment is applied to the
other occurrence (the run line at the second occurrence noted in the review).
package.json
Outdated
| "bin": "./bin/repomix.cjs", | ||
| "scripts": { | ||
| "prepack": "npm run build", | ||
| "prepack": "node --run build", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What Node.js version first introduced support for the node --run <script> CLI option?
💡 Result:
Node.js version 22.0.0 first introduced support for the node --run <script> CLI option as an experimental feature. The implementing pull request #52190 was merged on 2024-04-08, before the v22.0.0 release on 2024-04-24. It remained experimental until marked stable in pull request #53763, merged on 2024-09-21.
Citations:
- 1: cli: implement
node --run <script-in-package-json>nodejs/node#52190 - 2: src: mark
node --runas stable nodejs/node#53763 - 3: src: traverse parent folders while running
--runnodejs/node#53154
🏁 Script executed:
cat -n package.json | sed -n '20,26p'Repository: yamadashy/repomix
Length of output: 436
🏁 Script executed:
cat -n package.json | sed -n '122,126p'Repository: yamadashy/repomix
Length of output: 197
prepack script requires Node 22+, but engines declares Node 20+.
Line 22 uses node --run build, which requires Node 22.0.0 or later. However, Line 124 permits Node 20.0.0. This breaks prepack for Node 20 users in the declared support range.
Proposed fix
- "prepack": "node --run build",
+ "prepack": "pnpm run build",🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package.json` at line 22, The prepack script currently uses "prepack" with
"node --run build" which requires Node 22+, but the package.json "engines.node"
allows Node 20; update one of them so the declared engine range matches the
script: either change the "prepack" script to a Node-20-compatible command (for
example invoke the build via "npm run build" or another shell-safe build
invocation) or raise "engines.node" to >=22.0.0; touch the "prepack" entry
and/or the "engines.node" value in package.json (referencing the prepack script
name "prepack" and the engines field "engines.node") so they are consistent.
website/compose.yml
Outdated
| server: | ||
| build: | ||
| context: ./server | ||
| context: ./client | ||
| dockerfile: Dockerfile |
There was a problem hiding this comment.
Incorrect build context will cause Docker build failure.
The server service has context: ./client but the Dockerfile at website/server/Dockerfile expects the repository root as context. The Dockerfile copies pnpm-lock.yaml, pnpm-workspace.yaml, and .npmrc from the root level (see website/server/Dockerfile lines 14-15), which don't exist in ./client.
Compare with website/compose.bundle.yml lines 22-25, which correctly uses context: .. and dockerfile: website/server/Dockerfile.
🐛 Proposed fix
server:
build:
- context: ./client
- dockerfile: Dockerfile
+ context: ..
+ dockerfile: website/server/Dockerfile
ports:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| server: | |
| build: | |
| context: ./server | |
| context: ./client | |
| dockerfile: Dockerfile | |
| server: | |
| build: | |
| context: .. | |
| dockerfile: website/server/Dockerfile |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@website/compose.yml` around lines 18 - 21, The server service in the compose
file is using the wrong build context; update the server build block so context
points to the repository root (e.g., context: ..) and the dockerfile points to
the server Dockerfile (dockerfile: website/server/Dockerfile) to match how
compose.bundle.yml configures the server; modify the server build configuration
(service name: server, keys: context and dockerfile) accordingly so the files
copied in website/server/Dockerfile (pnpm-lock.yaml, pnpm-workspace.yaml,
.npmrc) are available during docker build.
|
PR review posted below |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
Please see below for full review |
PR Review: chore(deps): Migrate from npm to pnpm with workspace supportOverall well-structured migration. Issues found: Bug: website/compose.yml - Server build context is ./client (copy-paste error). Should be .. with dockerfile: website/server/Dockerfile like compose.bundle.yml. Will cause Docker build failures. node_modules in server Dockerfile - pnpm symlinks node_modules to .pnpm/ store. COPY of /app/node_modules/tinypool and tiktoken may not work. Verify in test build. npm audit signatures - npm-publish.yml still uses npm audit signatures. npm wont find package-lock.json. Replace with pnpm audit or remove. Heavy dev command - compose.yml server rebuilds entire monorepo on every start. Consider pre-building. Minor: --no-git-checks on publish is fine for CI but worth documenting. Browser CI uses working-directory instead of pnpm --filter (inconsistent). Perf-benchmark npm fallback is good transitional measure. Good: Pinned pnpm/action-setup SHA, corepack via packageManager field, workspace:* protocol, repomix-browser rename, Dockerfile layer caching, consistent corepack enable. Generated with Claude Code |
Replace npm's .npmrc min-release-age=7 (days) with pnpm's native minimumReleaseAge: 10080 (minutes = 7 days) in pnpm-workspace.yaml. The npm setting was silently ignored by pnpm. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Deploying repomix with
|
| Latest commit: |
64320e7
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://ea1e7e0f.repomix.pages.dev |
| Branch Preview URL: | https://chore-migrate-to-pnpm-worksp.repomix.pages.dev |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1275 +/- ##
=======================================
Coverage 87.18% 87.18%
=======================================
Files 115 115
Lines 4324 4324
Branches 1002 1002
=======================================
Hits 3770 3770
Misses 554 554 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
PR Review (Follow-up): chore(deps): Migrate from npm to pnpm with workspace supportPrevious review identified several issues. Here's an updated assessment after the two fix commits: Still UnresolvedBug:
Addressed by fix commitsThe Additional observationsDetails
Overall the migration is thorough and well-structured. The three items above (compose.yml context, npm audit, node --run compat) should be fixed before merge. Generated with Claude Code |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Root Dockerfile: - Use selective COPY instead of COPY . . to leverage Docker layer caching - Use pnpm install --filter repomix to skip workspace packages' deps - Use npm link instead of pnpm link --global (npm's global bin is in PATH) Cloud Build: - Add root .gcloudignore to reduce upload size when building server from repo root context (excludes node_modules, tests, .git, etc.) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
PR Review: chore(deps): Migrate from npm to pnpm with workspace supportOverall this is a well-executed migration. The workspace setup is clean, CI simplification is a clear win, and Docker layer caching improvements in the root Dockerfile are solid. A few issues to flag: Bug:
|
Own packages (@repomix/strip-comments, @repomix/tree-sitter-wasms) are trusted and should be installable immediately after publish. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
- Fix compose.yml server build context: ./client → .. (correct repo root) - Fix WASM path resolution in bundle.mjs: use import.meta.resolve() instead of hardcoded node_modules paths (pnpm symlink compatible) - Fix bundle.mjs buildTypeScript(): npm run build → pnpm run build - Remove npm audit signatures step (requires package-lock.json) - Fix prepack: node --run build → pnpm run build (Node 20 compat) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
tsconfig.build.json extends tsconfig.json, so both files are needed for the TypeScript build step. The selective COPY approach missed this. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
| context: ./server | ||
| dockerfile: Dockerfile | ||
| context: .. | ||
| dockerfile: website/client/Dockerfile |
There was a problem hiding this comment.
🟡 Development compose server service incorrectly builds from client Dockerfile
In website/compose.yml, the server service uses dockerfile: website/client/Dockerfile (line 21). Previously, it used the server's own Dockerfile (context: ./server, dockerfile: Dockerfile). Now the server development container is built from the client's Dockerfile, which exposes port 5173 and has a default CMD of pnpm run docs:dev — both client-specific. While this currently works because docker compose overrides the command and working_dir, it's fragile: any future client-specific changes to website/client/Dockerfile (e.g., adding Vue.js tooling or client dependencies) will unintentionally break the server's dev environment. Note that website/compose.bundle.yml:24-25 correctly uses dockerfile: website/server/Dockerfile for the bundled server.
Prompt for agents
In website/compose.yml line 21, the server service uses `dockerfile: website/client/Dockerfile` which is semantically wrong. The server should not depend on the client's Dockerfile. Two options to fix:
1. Create a shared lightweight development Dockerfile (e.g., `website/Dockerfile.dev`) with just `FROM node:24-alpine`, `RUN apk add --no-cache git && corepack enable`, and `WORKDIR /app`. Use this for both client and server in compose.yml.
2. Add a `development` target stage to `website/server/Dockerfile` (similar to what the client Dockerfile has), then use `dockerfile: website/server/Dockerfile` with `target: development` in the compose.yml server service build config.
Was this helpful? React with 👍 or 👎 to provide feedback.
Remove pnpm minimumReleaseAge as it conflicts with Renovate's rangeStrategy: bump — Renovate checks the bumped-to version (e.g. 2.4.7) but pnpm resolves the ^ range to a newer patch (e.g. 2.4.8) that may not meet the age constraint. Renovate already enforces minimumReleaseAge: 7 days at the PR creation level. Add ace-builds as explicit dependency of website/client — previously accessed as phantom dependency via vue3-ace-editor under npm's flat node_modules, but pnpm's isolated layout requires explicit declaration. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…mport Add minimumReleaseAge: 10080 (7 days) to pnpm-workspace.yaml to prevent installing package versions released less than 7 days ago. This complements Renovate's minimumReleaseAge by catching newer patches resolved via ^ ranges. Regenerate pnpm-lock.yaml using `pnpm import` from the original package-lock.json to preserve locked versions. The --frozen-lockfile flag in CI bypasses the age check for already-locked versions. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
pnpm移行のメリットが現状の運用（Renovate による依存管理、独立したサブパッケージ構成）に対して薄いと判断し、クローズします。 |
1 participant
Summary
Migrate the project from npm to pnpm as the package manager and set up pnpm workspaces to centralize dependency management across all sub-packages (browser, scripts/memory, website/client, website/server).
Changes
Package manager migration:
packageManagerfield,.tool-versions)package-lock.jsonfiles (5 total) with a singlepnpm-lock.yamlcorepack enableconsistently in all DockerfilesWorkspace setup:
pnpm-workspace.yamlwith 4 workspace packagesscripts/memorydependency:"file:../.."→"workspace:*"website/serverdependency:"github:yamadashy/repomix#main"→"workspace:*""repomix"to"repomix-browser"to avoid name collisionCI simplification:
pnpm/action-setup+pnpm install --frozen-lockfilenpm linkdance for website server — workspace resolves dependencies automaticallypnpm --filter <name>for sub-package commandsperf-benchmark.ymlincludes npm fallback for transition periodDocker updates:
corepack enable+pnpm link --globalChecklist
pnpm run test(113 files, 1086 tests passed)pnpm run lint(lint-ts, lint-secretlint passed)🤖 Generated with Claude Code