fix: refresh stale internal dependency pins (process, watch)#220
Merged
Conversation
When pnpm publishes, it rewrites workspace:* to the exact dependency version at publish time. Because these are 0.x packages (semver treats minor bumps as breaking), published pins do not pick up newer minors of their internal deps, so consumers end up with duplicate copies in their tree. Latest published packages had stale pins: - process@0.8.0 pinned context-api@0.5.3 (latest 0.6.0) - watch@0.4.4 pinned process@0.7.4 (latest 0.8.0) and fs@0.2.3 (latest 0.3.0) Patch-bump process (0.8.0 -> 0.8.1) and watch (0.4.4 -> 0.4.5) so the publish workflow republishes them with fresh pins (context-api@0.6.0, process@0.8.1, fs@0.3.0), eliminating the duplicate @effectionx/context-api reported by consumers.
📝 WalkthroughWalkthroughTwo package manifests receive patch version bumps: ChangesPackage Version Bumps
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes 🚥 Pre-merge checks | ✅ 6✅ Passed checks (6 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 |
commit: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
watch/package.json (1)
1-51:⚠️ Potential issue | 🟠 Major | ⚡ Quick winMissing 'files' field in package.json.
The package.json does not include a 'files' field. According to coding guidelines, every published package must declare a 'files' field that includes 'dist', 'mod.ts', and relevant source files. This controls which files are packaged in the published tarball.
✏️ Suggested fix: add 'files' field
"sideEffects": false, + "files": ["dist", "main.ts", "mod.ts"], "dependencies": {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@watch/package.json` around lines 1 - 51, The package.json file for the watch package is missing a 'files' field, which controls which files are included in the published tarball. Add a 'files' field to the package.json (at the root level alongside other metadata fields like "license", "author", etc.) that explicitly declares which files and directories should be included when publishing. The field should include at least 'dist' (the compiled output directory) and 'mod.ts' (the TypeScript source file), as referenced in the exports configuration. This ensures only necessary files are packaged and published with the module.Source: Coding guidelines
process/package.json (1)
1-44:⚠️ Potential issue | 🟠 Major | ⚡ Quick winMissing 'files' field in package.json.
The package.json does not include a 'files' field. According to coding guidelines, every published package must declare a 'files' field that includes 'dist', 'mod.ts', and relevant source files. This controls which files are packaged in the published tarball.
✏️ Suggested fix: add 'files' field
"sideEffects": false, + "files": ["dist", "mod.ts"], "dependencies": {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@process/package.json` around lines 1 - 44, The package.json is missing a required 'files' field that controls which files are included in the published package tarball. Add a 'files' field as a top-level property in the package.json object that includes an array with the entries 'dist', 'mod.ts', and any other relevant source files that should be distributed. This field should be added alongside other metadata fields like 'license', 'author', and 'repository'.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@process/package.json`:
- Line 1: Add the required 'files' field to both package.json files to control
which files are included in the published package. In process/package.json, add
"files": ["dist", "mod.ts"] before the 'dependencies' field. In
watch/package.json, add "files": ["dist", "main.ts", "mod.ts"] before the
'dependencies' field, since watch exports both main.ts and mod.ts as entry
points. This ensures only the dist directory and specified source entry-point
files are published, preventing unwanted files from being included in the
tarball.
---
Outside diff comments:
In `@process/package.json`:
- Around line 1-44: The package.json is missing a required 'files' field that
controls which files are included in the published package tarball. Add a
'files' field as a top-level property in the package.json object that includes
an array with the entries 'dist', 'mod.ts', and any other relevant source files
that should be distributed. This field should be added alongside other metadata
fields like 'license', 'author', and 'repository'.
In `@watch/package.json`:
- Around line 1-51: The package.json file for the watch package is missing a
'files' field, which controls which files are included in the published tarball.
Add a 'files' field to the package.json (at the root level alongside other
metadata fields like "license", "author", etc.) that explicitly declares which
files and directories should be included when publishing. The field should
include at least 'dist' (the compiled output directory) and 'mod.ts' (the
TypeScript source file), as referenced in the exports configuration. This
ensures only necessary files are packaged and published with the module.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 9b38b0d5-a209-4b47-ab5f-a9ba2bd039ee
📒 Files selected for processing (2)
process/package.jsonwatch/package.json
jbolda
approved these changes
Jun 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A consumer reported getting two copies of
@effectionx/context-apiin their dependency tree when using@effectionx/processalongside a direct, up-to-datecontext-apidependency.Root cause
Source packages declare internal deps as
workspace:*. Whenpnpm publishruns, it rewritesworkspace:*to the exact dependency version at publish time. Because these packages are pre-1.0 (0.x), semver treats every minor bump (0.5→0.6) as breaking — so a published exact pin likecontext-api: "0.5.3"will never dedupe against a newer0.6.0a consumer pulls in directly. Result: duplicate copies in the tree.The latest published packages had these stale pins:
process@0.8.0context-api: 0.5.3watch@0.4.4process: 0.7.4watch@0.4.4fs: 0.2.3Fix
Patch-bump the affected packages so the publish workflow (
.internal/publish-matrix.tsrepublishes any version not yet on npm) re-releases them, capturing fresh pins:@effectionx/process0.8.0→0.8.1(will pincontext-api@0.6.0)@effectionx/watch0.4.4→0.4.5(will pinprocess@0.8.1,fs@0.3.0)Since both are published from the same commit,
watchpicks up the newprocess@0.8.1, so the wholewatch → process → context-apichain resolves to a singlecontext-api@0.6.0.Follow-up (not in this PR)
This will recur whenever an internal dep gets a minor bump and its dependents aren't re-released. Worth considering changesets (auto-bumps dependents and rewrites pins) or widening pre-1.0 ranges so cross-minor dedupe works. Happy to open a separate issue.
Summary by CodeRabbit
@effectionx/processto 0.8.1 and@effectionx/watchto 0.4.5.