chore(deps): interface-core as bounded peer + dev dependency - #4
Merged
Conversation
| "rethinkdb-ts": "^2.7.0" | ||
| }, | ||
| "devDependencies": { | ||
| "@antelopejs/interface-core": "^0.0.5", |
There was a problem hiding this comment.
The
^0.0.5 specifier in devDependencies does not mirror the peer range. For 0.0.x versions, npm/pnpm treats the caret as a patch-level pin (>=0.0.5 <0.0.6), meaning the dev install is locked to exactly 0.0.5 while the peer range allows any 0.0.x up to 0.1.0. If a 0.0.6 patch is published that the peer range accepts, it won't be tested locally during development.
Suggested change
| "@antelopejs/interface-core": "^0.0.5", | |
| "@antelopejs/interface-core": ">=0.0.5 <0.1.0", |
Prompt To Fix With AI
This is a comment left during a code review.
Path: package.json
Line: 40
Comment:
The `^0.0.5` specifier in devDependencies does not mirror the peer range. For `0.0.x` versions, npm/pnpm treats the caret as a patch-level pin (`>=0.0.5 <0.0.6`), meaning the dev install is locked to exactly `0.0.5` while the peer range allows any `0.0.x` up to `0.1.0`. If a `0.0.6` patch is published that the peer range accepts, it won't be tested locally during development.
```suggestion
"@antelopejs/interface-core": ">=0.0.5 <0.1.0",
```
How can I resolve this? If you propose a fix, please make it concise.Interfaces are host-provided runtime singletons, so they move to peerDependencies. The range keeps the original lower bound (no forced upgrade) and is bounded to the current major (<1.0.0). devDependencies mirror the exact same range so local/CI builds exercise the full supported window, and the field is grouped with the other dependency sections.
Upd4ting
force-pushed
the
chore/peer-interface-deps
branch
from
June 15, 2026 21:52
2efe3f3 to
3962918
Compare
Member
Author
|
@greptileai review |
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
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.
Move
@antelopejs/interface-corefrom dependencies to peerDependencies (bounded to the current major, e.g.>=0.0.5 <0.1.0) and mirror it in devDependencies for standalone compilation. interface-core is a host-provided runtime singleton; this avoids dual installs and version-pinning overrides downstream. Verified: install, build, lint.Greptile Summary
This PR moves
@antelopejs/interface-corefromdependenciestopeerDependencies(with a mirrored entry indevDependencies), correctly treating it as a host-provided singleton to avoid duplicate installs and downstream version-pinning conflicts.@antelopejs/interface-coreis removed from runtimedependenciesand added to bothpeerDependenciesanddevDependencieswith the range>=0.0.3 <1.0.0, allowing the dev environment to build and the consuming host to supply the package.0.0.3.Confidence Score: 5/5
Safe to merge — the dependency restructuring is mechanically correct, and the dev and peer ranges are now consistent with each other.
The change correctly removes interface-core from runtime dependencies and places it in both peerDependencies and devDependencies with matching ranges. The only open question is whether the upper bound should be <0.1.0 rather than <1.0.0, since the PR description's example suggested a tighter bound — but this is a minor design choice, not a defect in the restructuring itself.
package.json — worth confirming the intended upper bound of the peer range (<0.1.0 vs <1.0.0).
Important Files Changed
Flowchart
%%{init: {'theme': 'neutral'}}%% flowchart TD A[interface-rethinkdb] --> B[peerDependencies: interface-core >=0.0.3 <1.0.0] A --> C[devDependencies: interface-core >=0.0.3 <1.0.0] A --> D[dependencies: rethinkdb-ts ^2.7.0] E[Downstream consumer app] --> F[installs interface-core as host singleton] E --> G[installs interface-rethinkdb] G --> B F -. satisfies peer .-> B%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%% flowchart TD A[interface-rethinkdb] --> B[peerDependencies: interface-core >=0.0.3 <1.0.0] A --> C[devDependencies: interface-core >=0.0.3 <1.0.0] A --> D[dependencies: rethinkdb-ts ^2.7.0] E[Downstream consumer app] --> F[installs interface-core as host singleton] E --> G[installs interface-rethinkdb] G --> B F -. satisfies peer .-> BReviews (2): Last reviewed commit: "chore(deps): interface deps as bounded p..." | Re-trigger Greptile