-
Notifications
You must be signed in to change notification settings - Fork 1
feat: add support for exact version flag in add method #29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughAdds an optional exact parameter to Manager.add/add! and implementations (npm, pnpm, yarn classic/berry, bun) so callers can request manager-specific exact-install flags (--exact / --save-exact) when adding packages; updates signatures, tests, RBS, README and changelog. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Manager
participant CLI as "Package Manager CLI"
User->>Manager: add(["[email protected]"], exact: true)
Manager->>Manager: exact_flag(true) => "--exact" / "--save-exact"
Manager->>Manager: build flags = [type_flag, exact_flag].compact
Manager->>CLI: raw("add" / "install", flags + packages)
CLI-->>Manager: install result (success/failure)
Manager-->>User: return result
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (4 passed)
✨ 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 |
|
I'm on the fence about this because using exact versions shouldn't be required |
|
@claude review this PR |
|
Claude finished @justin808's task —— View job PR Review CompleteTasks
Code ReviewI've reviewed this PR and the implementation looks excellent overall. The code is clean, consistent, and well-tested. Here are my findings: Strengths
Minor Observations
Suggestions for Consideration
SummaryThis PR is well-implemented with:
The implementation follows established patterns in the codebase and integrates seamlessly with existing functionality. I recommend approval with the optional documentation enhancement noted above. |
Code Review for PR #29SummaryThis PR adds support for the ✅ Strengths1. Excellent Test Coverage
2. Consistent Implementation Pattern
3. Good Documentation
4. API Design
💡 Observations & Minor Suggestions1. Documentation EnhancementThe README.md hasn't been updated to document this new feature. Consider adding an entry to the "Adding dependencies" section: # adds react-on-rails with exact version (no ^ or ~)
package_json.manager.add(["[email protected]"], exact: true)This would help users discover the feature. Reference: README.md:169-184 2. Potential Edge CaseThe implementation correctly passes the raise_exited_with_non_zero_code_error unless add(packages, type: type, exact: exact)This is correct, but I notice there's a minor inconsistency in the 3. Implementation ConsistencyAll implementations correctly use: flags = [package_type_install_flag(type), exact_flag(exact)].compact
raw("add", flags + packages)This is excellent - the ordering ensures flags come before package names, which is what all package managers expect. 4. Test QualityThe test for multiple packages in yarn_classic_like_spec.rb:182-195 using 🔒 Security Considerations✅ No security concerns identified:
⚡ Performance Considerations✅ No performance issues:
🐛 Potential Bugs✅ No bugs identified:
📊 Overall AssessmentRecommendation: ✅ APPROVE This is a well-implemented feature that:
The only minor improvement would be updating the README.md to document the new Great work! 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
🧹 Nitpick comments (2)
spec/package_json/managers/bun_like_spec.rb (1)
152-178: Consider adding test for multiple packages with exact flag.The tests cover production and dev dependencies with exact versions, but
yarn_classic_like_spec.rbincludes an additional test case for multiple packages (lines 181-194 in that file). Adding a similar test here would provide consistent coverage across all package managers.Example test case:
it "supports adding multiple packages with exact version" do with_package_json_file do result = manager.add(%w[example example2], exact: true) expect(result).to be(true) expect_manager_to_be_invoked_with("add --exact example example2") expect_package_json_with_content({ "dependencies" => { "example" => "0.0.0", "example2" => "0.0.0" } }) end endspec/package_json/managers/pnpm_like_spec.rb (1)
155-181: Consider adding test for multiple packages with exact flag.Similar to the bun_like tests, this file would benefit from a test case for multiple packages with exact versions for consistency with
yarn_classic_like_spec.rb(lines 181-194).Example test case:
it "supports adding multiple packages with exact version" do with_package_json_file do result = manager.add(%w[example example2], exact: true) expect(result).to be(true) expect_manager_to_be_invoked_with("add --save-prod --save-exact example example2") expect_package_json_with_content({ "dependencies" => { "example" => "0.0.0", "example2" => "0.0.0" } }) end end
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Gemfile.lockis excluded by!**/*.lock
📒 Files selected for processing (18)
.editorconfig(1 hunks).gitattributes(1 hunks).github/workflows/claude-code-review.yml(1 hunks).github/workflows/claude.yml(0 hunks).gitignore(1 hunks)README.md(1 hunks)lib/package_json/managers/base.rb(1 hunks)lib/package_json/managers/bun_like.rb(2 hunks)lib/package_json/managers/npm_like.rb(2 hunks)lib/package_json/managers/pnpm_like.rb(2 hunks)lib/package_json/managers/yarn_berry_like.rb(2 hunks)lib/package_json/managers/yarn_classic_like.rb(2 hunks)package.json(1 hunks)spec/package_json/managers/bun_like_spec.rb(1 hunks)spec/package_json/managers/npm_like_spec.rb(1 hunks)spec/package_json/managers/pnpm_like_spec.rb(1 hunks)spec/package_json/managers/yarn_berry_like_spec.rb(1 hunks)spec/package_json/managers/yarn_classic_like_spec.rb(1 hunks)
💤 Files with no reviewable changes (1)
- .github/workflows/claude.yml
🧰 Additional context used
🧬 Code graph analysis (11)
lib/package_json/managers/yarn_berry_like.rb (5)
lib/package_json/managers/base.rb (2)
add(46-48)raw(119-121)lib/package_json/managers/bun_like.rb (3)
add(19-22)package_type_install_flag(72-83)exact_flag(66-70)lib/package_json/managers/npm_like.rb (3)
add(25-28)package_type_install_flag(76-87)exact_flag(70-74)lib/package_json/managers/pnpm_like.rb (3)
add(19-22)package_type_install_flag(77-88)exact_flag(71-75)lib/package_json/managers/yarn_classic_like.rb (3)
add(19-22)package_type_install_flag(88-99)exact_flag(82-86)
spec/package_json/managers/yarn_classic_like_spec.rb (4)
spec/support/temp_helpers.rb (1)
with_package_json_file(14-22)lib/package_json/managers/base.rb (1)
add(46-48)lib/package_json/managers/yarn_classic_like.rb (1)
add(19-22)spec/support/expect_helpers.rb (2)
expect_manager_to_be_invoked_with(69-76)expect_package_json_with_content(63-67)
lib/package_json/managers/yarn_classic_like.rb (5)
lib/package_json/managers/base.rb (2)
add(46-48)raw(119-121)lib/package_json/managers/bun_like.rb (3)
add(19-22)package_type_install_flag(72-83)exact_flag(66-70)lib/package_json/managers/npm_like.rb (3)
add(25-28)package_type_install_flag(76-87)exact_flag(70-74)lib/package_json/managers/pnpm_like.rb (3)
add(19-22)package_type_install_flag(77-88)exact_flag(71-75)lib/package_json/managers/yarn_berry_like.rb (3)
add(19-22)package_type_install_flag(74-85)exact_flag(68-72)
lib/package_json/managers/pnpm_like.rb (3)
lib/package_json/managers/base.rb (2)
add(46-48)raw(119-121)lib/package_json/managers/bun_like.rb (3)
add(19-22)package_type_install_flag(72-83)exact_flag(66-70)lib/package_json/managers/npm_like.rb (3)
add(25-28)package_type_install_flag(76-87)exact_flag(70-74)
spec/package_json/managers/bun_like_spec.rb (4)
spec/support/temp_helpers.rb (1)
with_package_json_file(14-22)lib/package_json/managers/base.rb (1)
add(46-48)lib/package_json/managers/bun_like.rb (1)
add(19-22)spec/support/expect_helpers.rb (2)
expect_manager_to_be_invoked_with(69-76)expect_package_json_with_content(63-67)
spec/package_json/managers/pnpm_like_spec.rb (8)
spec/support/temp_helpers.rb (1)
with_package_json_file(14-22)lib/package_json/managers/base.rb (1)
add(46-48)lib/package_json/managers/bun_like.rb (1)
add(19-22)lib/package_json/managers/npm_like.rb (1)
add(25-28)lib/package_json/managers/pnpm_like.rb (1)
add(19-22)lib/package_json/managers/yarn_berry_like.rb (1)
add(19-22)lib/package_json/managers/yarn_classic_like.rb (1)
add(19-22)spec/support/expect_helpers.rb (2)
expect_manager_to_be_invoked_with(69-76)expect_package_json_with_content(63-67)
lib/package_json/managers/bun_like.rb (5)
lib/package_json/managers/base.rb (2)
add(46-48)raw(119-121)lib/package_json/managers/npm_like.rb (3)
add(25-28)package_type_install_flag(76-87)exact_flag(70-74)lib/package_json/managers/pnpm_like.rb (3)
add(19-22)package_type_install_flag(77-88)exact_flag(71-75)lib/package_json/managers/yarn_berry_like.rb (3)
add(19-22)package_type_install_flag(74-85)exact_flag(68-72)lib/package_json/managers/yarn_classic_like.rb (3)
add(19-22)package_type_install_flag(88-99)exact_flag(82-86)
lib/package_json/managers/npm_like.rb (5)
lib/package_json/managers/base.rb (2)
add(46-48)raw(119-121)lib/package_json/managers/bun_like.rb (3)
add(19-22)package_type_install_flag(72-83)exact_flag(66-70)lib/package_json/managers/pnpm_like.rb (3)
add(19-22)package_type_install_flag(77-88)exact_flag(71-75)lib/package_json/managers/yarn_berry_like.rb (3)
add(19-22)package_type_install_flag(74-85)exact_flag(68-72)lib/package_json/managers/yarn_classic_like.rb (3)
add(19-22)package_type_install_flag(88-99)exact_flag(82-86)
lib/package_json/managers/base.rb (5)
lib/package_json/managers/bun_like.rb (1)
add(19-22)lib/package_json/managers/npm_like.rb (1)
add(25-28)lib/package_json/managers/pnpm_like.rb (1)
add(19-22)lib/package_json/managers/yarn_berry_like.rb (1)
add(19-22)lib/package_json/managers/yarn_classic_like.rb (1)
add(19-22)
spec/package_json/managers/npm_like_spec.rb (3)
spec/support/temp_helpers.rb (1)
with_package_json_file(14-22)lib/package_json/managers/npm_like.rb (1)
add(25-28)spec/support/expect_helpers.rb (2)
expect_manager_to_be_invoked_with(69-76)expect_package_json_with_content(63-67)
spec/package_json/managers/yarn_berry_like_spec.rb (3)
spec/support/temp_helpers.rb (1)
with_package_json_file(14-22)lib/package_json/managers/yarn_berry_like.rb (1)
add(19-22)spec/support/expect_helpers.rb (2)
expect_manager_to_be_invoked_with(69-76)expect_package_json_with_content(63-67)
🔇 Additional comments (19)
.gitattributes (1)
1-4: Good infrastructure setup for Yarn monorepo tooling.The
.gitattributesconfiguration properly marks Yarn-related files and directories with appropriate attributes. Marking.yarn/aslinguist-vendoredexcludes it from language statistics (standard practice for vendor directories), and tagging Yarn releases, plugins, and PnP files asbinaryandlinguist-generatedcorrectly reflects their nature as build/tooling artifacts..github/workflows/claude-code-review.yml (1)
1-59: Scope concern: workflow configuration changes not related to PR objectives.This PR is titled "feat: add support for exact version flag in add method," but the only file under review is a GitHub Actions workflow configuration. Per the PR summary, changes should be in the
Baseclass, package manager implementations, and test files. Please verify if this workflow file change is intentional or if the actual implementation files are missing from this review.README.md (2)
181-182: LGTM! Clear example of exact flag usage.The example effectively demonstrates the practical use case mentioned in issue #25 (React on Rails requiring exact version matching between gem and npm package).
185-189: LGTM! Documentation clearly describes the exact option.The updated table properly documents the new
exactparameter, its default behavior, and its effect on version prefixes.lib/package_json/managers/base.rb (1)
43-56: LGTM! Base class correctly defines the exact parameter.The implementation properly:
- Adds the
exactparameter with a sensible default (false) for backward compatibility- Documents the parameter via
@paramcomments- Forwards the parameter from
add!()toadd()- Follows the same pattern as the existing
typeparameterspec/package_json/managers/yarn_classic_like_spec.rb (1)
153-194: LGTM! Comprehensive test coverage for exact flag.The tests thoroughly validate:
- Production dependencies with exact version
- Dev dependencies with exact version
- Multiple packages with exact version
- Correct command invocation (with
--exactflag)- Correct package.json content (version without
^prefix).editorconfig (1)
4-8: The review comment contradicts its own evidence.The code snippet labeled "final state" explicitly shows
charset = utf-8is present at line 4, yet the comment claims this setting was removed. The current .editorconfig file matches the provided code snippet exactly and containscharset = utf-8. Additionally,trim_trailing_whitespacedoes not appear in the current file or the snippet provided.The concern about removal of these settings is not supported by the code changes shown.
Likely an incorrect or invalid review comment.
spec/package_json/managers/yarn_berry_like_spec.rb (1)
158-184: LGTM! Comprehensive test coverage for exact version installation.The test cases properly verify both production and dev dependency installation with exact versions. The assertions correctly check command invocation (
add --exactandadd --dev --exact) and package.json content ("0.0.0"instead of"^0.0.0").spec/package_json/managers/npm_like_spec.rb (1)
153-179: LGTM! Tests correctly verify npm's exact version flag.The test cases properly exercise the npm-specific
--save-exactflag and verify both command invocation and package.json updates. The implementation correctly distinguishes npm's flag from yarn/bun's--exact.lib/package_json/managers/yarn_classic_like.rb (2)
19-21: LGTM! Clean implementation of exact version support.The method properly integrates the
exactparameter with the existingtypeparameter, using.compactto cleanly handle optional flags.
82-86: LGTM! Correct flag for Yarn Classic.The helper correctly returns
--exactfor Yarn Classic, consistent with the package manager's documented behavior.lib/package_json/managers/bun_like.rb (2)
19-21: LGTM! Consistent implementation across managers.The implementation follows the established pattern used in other package managers, ensuring a consistent API surface.
66-70: LGTM! Correct flag for Bun.The helper correctly returns
--exactfor Bun, aligning with Bun's package manager behavior.lib/package_json/managers/npm_like.rb (2)
25-27: LGTM! Proper integration with npm's install command.The implementation correctly combines the exact flag with npm's existing install command structure.
70-74: LGTM! Correct flag for npm.The helper correctly returns
--save-exactfor npm, which differs from yarn/bun's--exactflag. This is the proper npm-specific flag for saving exact versions.lib/package_json/managers/yarn_berry_like.rb (2)
19-21: LGTM! Consistent implementation for Yarn Berry.The implementation maintains consistency with other managers while properly supporting Yarn Berry's exact version flag.
68-72: LGTM! Correct flag for Yarn Berry.The helper correctly returns
--exactfor Yarn Berry, consistent with both classic and modern Yarn versions.lib/package_json/managers/pnpm_like.rb (2)
19-21: LGTM! Proper integration with pnpm's add command.The implementation correctly integrates the exact flag with pnpm's existing command structure, following the same pattern as other managers.
71-75: LGTM! Correct flag for pnpm.The helper correctly returns
--save-exactfor pnpm, which follows npm's flag convention rather than yarn/bun's--exact.
.gitignore
Outdated
| .yarn/* | ||
| !.yarn/patches | ||
| !.yarn/plugins | ||
| !.yarn/releases | ||
| !.yarn/sdks | ||
| !.yarn/versions | ||
|
|
||
| node_modules/ | ||
| .idea/ | ||
| .vscode/ | ||
| # Whether you use PnP or not, the node_modules folder is often used to store | ||
| # build artifacts that should be gitignored | ||
| node_modules | ||
|
|
||
| # rspec failure tracking | ||
| .rspec_status | ||
| # Swap the comments on the following lines if you wish to use zero-installs | ||
| # In that case, don't forget to run `yarn config set enableGlobalCache false`! | ||
| # Documentation here: https://yarnpkg.com/features/caching#zero-installs | ||
|
|
||
| #!.yarn/cache | ||
| .pnp.* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Yarn zero-installs infrastructure changes not mentioned in PR objectives.
The .gitignore changes introduce comprehensive support for Yarn's zero-installs feature, including patterns for .yarn/*, PnP artifacts, and related documentation. While these are valid infrastructure improvements, they appear unrelated to the exact version flag feature and aren't mentioned in the PR description or linked issue #25.
Consider either:
- Updating the PR description to explain these infrastructure changes
- Moving these changes to a separate PR focused on Yarn setup
I'll verify the review comment by investigating the PR context and whether the .gitignore changes are actually scope creep.
</script>🏁 Script executed:
#!/bin/bash
# Extract PR and git context to understand the actual scope
echo "=== Git log (recent commits) ==="
git log --oneline -10
echo -e "\n=== Git show HEAD (current commit details) ==="
git show --stat HEAD
echo -e "\n=== Git diff HEAD^ (changes in latest commit) ==="
git diff HEAD^ --name-only 2>/dev/null || echo "No previous commit available"
echo -e "\n=== Check for PR/commit metadata or description files ==="
if [ -f ".github/pull_request_template.md" ]; then
echo "Found PR template:"
head -20 .github/pull_request_template.md
fi
echo -e "\n=== Look for recent commits mentioning .gitignore or Yarn ==="
git log --oneline --all --grep="gitignore\|yarn\|Yarn" -10 2>/dev/null || echo "No matching commits found"Length of output: 1750
I need to find when and if the .gitignore changes mentioned in the review actually exist in this PR branch.
🏁 Script executed:
#!/bin/bash
# Check current .gitignore and its history
echo "=== Current .gitignore content ==="
cat .gitignore 2>/dev/null || echo "File not found"
echo -e "\n=== Git log for .gitignore (last 15 commits touching it) ==="
git log --oneline -15 -- .gitignore 2>/dev/null || echo "No history found"
echo -e "\n=== Git blame on .gitignore (first 20 lines) ==="
git blame .gitignore 2>/dev/null | head -20 || echo "Cannot blame file"
echo -e "\n=== Check if .gitignore is modified/staged in current branch ==="
git status .gitignore 2>/dev/null || echo "Not tracked or no changes"
echo -e "\n=== Git show for .gitignore on recent commits ==="
git show HEAD:.gitignore 2>/dev/null | head -20 || echo "Not in HEAD"
git show HEAD~5:.gitignore 2>/dev/null | head -20 || echo "Not in HEAD~5"Length of output: 2841
I need to determine what files are actually new in this PR by finding the merge base.
</script>🏁 Script executed:
#!/bin/bash
# Determine what's new in this PR vs the base
echo "=== Current branch and merge info ==="
git branch -vv
git log --oneline --decorate -5
echo -e "\n=== Find merge base (PR base commit) ==="
MERGE_BASE=$(git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main 2>/dev/null || echo "unknown")
echo "Merge base: $MERGE_BASE"
if [ "$MERGE_BASE" != "unknown" ]; then
echo -e "\n=== Files changed in this PR (from merge base to HEAD) ==="
git diff --name-only $MERGE_BASE..HEAD
echo -e "\n=== .gitignore changes in this PR ==="
git diff $MERGE_BASE..HEAD -- .gitignore 2>/dev/null || echo ".gitignore not changed in this PR"
fi
echo -e "\n=== Commit that modified .gitignore (a8cbff1) details ==="
git show a8cbff1 --stat 2>/dev/null | head -30 || echo "Cannot show commit"Length of output: 960
Let me compare the .gitignore directly between the current branch and main.
</script>🏁 Script executed:
#!/bin/bash
# Compare .gitignore between branches directly
echo "=== .gitignore on main branch ==="
git show main:.gitignore 2>/dev/null || git show origin/main:.gitignore 2>/dev/null || echo "Cannot access main"
echo -e "\n=== .gitignore on current branch (HEAD) ==="
cat .gitignore
echo -e "\n=== Direct diff: main vs HEAD on .gitignore ==="
git diff main .gitignore 2>/dev/null || git diff origin/main .gitignore 2>/dev/null || echo "Cannot diff with main"
echo -e "\n=== PR description or commit message context ==="
git log --format="%H %s" a8cbff1..37297fb 2>/dev/null | head -20Length of output: 1688
Let me examine the project context and the actual feature implementation to determine if these .gitignore changes are necessary for the "exact version flag" feature.
</script>🏁 Script executed:
#!/bin/bash
# Understand the project and feature context
echo "=== package.json content ==="
cat package.json 2>/dev/null || echo "No package.json"
echo -e "\n=== README header to understand project type ==="
head -30 README.md
echo -e "\n=== Check commit 20e1c04 (exact version flag feature) ==="
git show 20e1c04 --stat 2>/dev/null | head -40
echo -e "\n=== Look at lib/yarn_add.rb (likely implementation) ==="
find . -name "*yarn*" -type f -o -name "*add*" -type f | grep -E '\.(rb|js)$' | head -10Length of output: 3652
Scope creep confirmed: .gitignore infrastructure changes are unrelated to exact version flag feature.
The .gitignore modifications replace Ruby/Rails patterns with Yarn/zero-installs patterns—a complete infrastructure overhaul unrelated to the exact version flag feature added in commit 20e1c04. These changes are new to this PR and represent bundled scope that should either be documented in the PR description or separated into a dedicated infrastructure PR.
Consider updating the PR description to explain these project setup changes or moving them to a separate PR focused on Yarn configuration.
🤖 Prompt for AI Agents
In .gitignore around lines 1 to 17, you added Yarn/zero-install and related
entries that are unrelated to the "exact version flag" feature; either remove
these infrastructure changes from this branch and submit them in a dedicated
infra PR, or keep them but update the current PR description to explicitly
document the .gitignore/Yarn changes and why they belong here (include
rationale, migration steps, and any developer impact). Ensure the PR only
contains feature changes or clearly-labelled infra changes to avoid scope creep.
package.json
Outdated
| { | ||
| "name": "package_json-20251102-36220-vfpcqr", | ||
| "packageManager": "[email protected]" | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove test artifact from repository.
This package.json file appears to be a test artifact with an auto-generated name (package_json-20251102-36220-vfpcqr) that includes a timestamp and random identifier. Test artifacts should not be committed to the repository.
Please remove this file from the commit. If package.json files are created during testing, ensure they are properly cleaned up or covered by .gitignore patterns.
🤖 Prompt for AI Agents
In package.json around lines 1 to 4, this file is a test artifact
(auto-generated name with timestamp/random id) and must be removed from the
commit; delete the file from the repository (git rm --cached or git rm if
already committed) and update the commit, then add a rule to .gitignore to
prevent auto-generated package.json files (or the test output directory) from
being committed and modify the test or build scripts to clean up temporary
package.json files after tests (or write them to a tmp directory) so they are
not left in the workspace.
Code Review - PR #29: Add support for exact version flagSummaryThis PR successfully adds support for the ✅ Strengths1. Excellent Code Quality
2. Comprehensive Documentation
3. Excellent Test Coverage
4. Backward Compatibility
|
PR Review: Add Exact Version Flag SupportThank you for this well-structured PR! The implementation adds valuable functionality for precise dependency version management. Here's my detailed review: ✅ Strengths
|
- Add exact parameter to add() and add!() methods across all package managers - Implement exact_flag() helper in each manager: - yarn/bun: --exact - npm/pnpm: --save-exact - Add comprehensive tests for all package managers (yarn classic, yarn berry, npm, pnpm, bun) - Tests verify exact versions are saved without ^ or ~ prefix - All tests pass with 100% line and branch coverage - No RuboCop violations in changed files Resolves #25 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
- Add YARD documentation to add() and add!() methods explaining all parameters - Add test for adding multiple packages with exact flag - Fix RuboCop style issue (use %w instead of array of strings) - All tests pass: 287 examples, 0 failures, 100% coverage 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
- Add README documentation with exact flag example - Add CHANGELOG entry for new feature - Add multi-package exact test to all manager specs (npm, pnpm, bun, yarn berry) - Add test for exact with optional dependencies - All tests pass: 294 examples, 100% coverage 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
1631700 to
17c97fd
Compare
Pull Request Review - PR #29SummaryThis PR adds support for the ✅ Strengths1. Excellent Code Consistency
2. Comprehensive Test Coverage
3. Good Documentation
4. Backward Compatibility
🔍 Code Quality ObservationsImplementation PatternThe implementation follows a consistent pattern across all managers: def add(packages, type: :production, exact: false)
flags = [package_type_install_flag(type), exact_flag(exact)].compact
raw("add", flags + packages)
end
def exact_flag(exact)
return "--exact" if exact # or "--save-exact" for npm/pnpm
nil
endThis is clean and maintainable. The use of Method SignaturesThe YARD documentation in # @param packages [Array<String>] the packages to add
# @param type [Symbol] the type of dependency (:production, :dev, :optional)
# @param exact [Boolean] if true, saves packages with exact versions (no ^ or ~ prefix)💭 Minor Suggestions (Optional)1. Consider Edge Case TestingWhile the test coverage is comprehensive, you might consider adding a test for:
However, this is a minor point - the current implementation correctly passes the exact flag to the package manager, which will handle this appropriately. 2. CHANGELOG Format CheckThe CHANGELOG entry looks good and follows the format: - Add support for `exact` parameter in `add` method to install packages with
exact versions ([#29](https://github.com/shakacode/package_json/pull/29) by
[@justin808](https://github.com/justin808))This correctly uses 🔒 Security & Performance
🎯 Final AssessmentThis PR is excellent and ready to merge. ✅ The implementation is:
Great work on this feature addition! The uniform implementation across all package managers and comprehensive test coverage demonstrate high code quality. Recommendation: Approve and merge. |
|
Possible merge commit message: |
G-Rath
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you need to update the types in the rbs files
- Remove YARD @param documentation from add() and add!() methods - Add exact parameter to RBS type signatures in base.rbs - Update CLAUDE.md with RBS documentation guidelines This project uses RBS for type documentation, not YARD comments. Types should be defined in sig/*.rbs files, keeping Ruby code clean. Addresses review feedback from @G-Rath in PR #29 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Code Review - PR #29: Add support for exact version flagSummaryThis PR successfully implements support for the Positive Aspects ✅
Minor Observations 🔍
Potential Improvements (Optional, Not Blocking) 💡These are minor suggestions for consideration, but the PR is ready to merge as-is:
Verdict ✅Approved - Excellent work! This PR demonstrates:
The implementation correctly addresses issue #25 and adds a valuable feature to the gem. All code quality requirements from CLAUDE.md appear to be met (RuboCop compliance, proper documentation approach, etc.). Ready to merge! 🚀 Review generated by Claude Code |
Pull Request ReviewExcellent work on implementing the ✅ Strengths1. Consistent Implementation
2. Excellent Test Coverage
3. Type Safety
4. Documentation
5. API Design
🔍 Code Quality ObservationsImplementation Pattern (lib/package_json/managers/npm_like.rb:25-27) def add(packages, type: :production, exact: false)
flags = [package_type_install_flag(type), exact_flag(exact)].compact
raw("install", flags + packages)
endThis is clean and idiomatic Ruby. The use of Helper Method Pattern (lib/package_json/managers/npm_like.rb:70-74) def exact_flag(exact)
return "--save-exact" if exact
nil
endThis follows the existing codebase patterns perfectly. Consistent with 📝 Minor Suggestions1. Consider Guard Clause Simplification (Optional, stylistic) def exact_flag(exact)
"--save-exact" if exact
endThis is functionally identical (implicit 2. CHANGELOG Format ✅ 🎯 Final AssessmentNo blocking issues found. This PR is production-ready.
The implementation is consistent, well-tested, properly typed, and follows the repository's conventions. The feature resolves issue #25 and provides a clean API that works across all supported package managers. Recommendation: Approve and merge 🚀 Review performed by Claude Code |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
CLAUDE.md (1)
82-88: Helpful documentation addition aligning with the RBS signature changes.The new section clarifies the project's use of RBS for type documentation, which directly supports the signature additions in this PR.
Optional: Address markdown formatting hint.
The linter suggests line 84 uses emphasis (bold text) where a heading might be more appropriate. Consider changing:
-**This project uses RBS (Ruby Signature) files for type documentation** +### RBS Usage + +This project uses RBS (Ruby Signature) files for type documentation.However, the current format is perfectly readable and this is just a stylistic suggestion.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
CLAUDE.md(1 hunks)sig/package_json/managers/bun_like.rbs(1 hunks)sig/package_json/managers/npm_like.rbs(1 hunks)sig/package_json/managers/pnpm_like.rbs(1 hunks)sig/package_json/managers/yarn_berry_like.rbs(1 hunks)sig/package_json/managers/yarn_classic_like.rbs(1 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.18.1)
CLAUDE.md
84-84: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
⏰ 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). (15)
- GitHub Check: test (windows-latest, head)
- GitHub Check: test (windows-latest, 3.1)
- GitHub Check: test (macos-latest, 3.0)
- GitHub Check: test (macos-latest, 3.1)
- GitHub Check: test (windows-latest, 2.7)
- GitHub Check: test (windows-latest, 3.0)
- GitHub Check: test (windows-latest, 2.6)
- GitHub Check: test (macos-latest, 2.6)
- GitHub Check: test (macos-latest, head)
- GitHub Check: test (macos-latest, 2.7)
- GitHub Check: test (ubuntu-latest, head)
- GitHub Check: test (ubuntu-latest, 2.6)
- GitHub Check: test (ubuntu-latest, 3.0)
- GitHub Check: test (ubuntu-latest, 3.1)
- GitHub Check: test (ubuntu-latest, 2.7)
🔇 Additional comments (5)
sig/package_json/managers/bun_like.rbs (1)
16-17: LGTM! Signature is consistent and correct.The
exact_flagmethod signature is well-defined and aligns with the implementation pattern across all package managers.sig/package_json/managers/pnpm_like.rbs (1)
16-17: LGTM! Signature matches the pattern.The signature is consistent with other package manager implementations.
sig/package_json/managers/yarn_berry_like.rbs (1)
16-17: LGTM! Consistent signature.The signature correctly follows the established pattern for all package managers.
sig/package_json/managers/npm_like.rbs (1)
14-15: LGTM! Signature is correct.The signature is consistent with the pattern established across all package manager implementations.
sig/package_json/managers/yarn_classic_like.rbs (1)
18-19: LGTM! Signature follows the pattern.The signature is consistent with all other package manager implementations.
Summary
This PR adds support for the
exactparameter to theaddmethod, allowing packages to be installed with exact version numbers (without^or~prefixes).Changes
exactparameter toadd()andadd!()methods in theBaseclassexact_flag()helper method in all package manager classes:--exact--save-exact--save-exact--exact0.0.0instead of^0.0.0)API Usage
Test Results
Related
Resolves #25
🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes
New Features
exactoption to install dependencies with exact version pinning across npm, yarn, pnpm, and bun-like managers.Documentation
exactbehavior.Tests