Update preinstall script to enable use as a Git dependency

[alexeyr-ci2]

Summary

Documented use as a Git dependency and fixed an issue with the Pro Node renderer there.

Pull Request checklist

• Add/update test to cover these changes
• Update documentation
• Update CHANGELOG file

---

This change is 

Summary by CodeRabbit

• Bug Fixes

  • Packages can now be installed as Git dependencies.
  • Install is more resilient to optional local-link steps, reducing install failures.

• Documentation

  • Contributor guide expanded with detailed testing workflows (local, Git, tarball), example app guidance, updated JS/Ruby flows, troubleshooting, and setup best practices.
  • Changelog anchor labels normalized for consistent linking.

[coderabbitai]

Walkthrough

Updates docs to document Git dependency installs and expand external-app testing guidance; moves react_on_rails_pro preinstall logic from an inline package.json script into a dedicated Node script and adds it to package files.

Changes

Cohort / File(s)	Summary
Changelog CHANGELOG.md	Adds a "Bug Fixes" subsection under Unreleased noting that all packages can be installed as Git dependencies; normalizes [Unreleased] anchor to [unreleased].
Contributor guidance CONTRIBUTING.md	Reworks testing guidance into "Example apps" and distinct sections for Ruby/JS/Git/tarball approaches; converts local path examples to URLs, updates yalc/publish commands and ports, adds troubleshooting and best-practice notes.
Preinstall workflow react_on_rails_pro/package.json, react_on_rails_pro/script/preinstall.js	Adds script/preinstall.js to files and replaces inline preinstall script with node ./script/preinstall.js. New script skips running inside node_modules, runs yarn run link-source then yalc add --link react-on-rails if possible, logs errors but exits 0 to avoid failing installs.

Sequence Diagram(s)

sequenceDiagram
    autonumber
    actor Developer
    participant Installer as npm/yarn
    participant pkg as package.json (preinstall)
    participant script as preinstall.js
    participant cmds as link-source & yalc

    Developer->>Installer: run install
    Installer->>pkg: invoke preinstall
    pkg->>script: node ./script/preinstall.js

    rect rgb(246, 250, 240)
    note right of script: guard — detect if inside node_modules
    script->>script: check path contains "node_modules"?
    alt inside node_modules
        script-->>pkg: log skip, exit 0
    else
        script->>cmds: run "yarn run link-source"
        cmds-->>script: success / error
        script->>cmds: run "yalc add --link react-on-rails"
        cmds-->>script: success / error
        alt any error
            script-->>pkg: log error, exit 0
        else
            script-->>pkg: complete, exit 0
        end
    end
    end

    pkg-->>Installer: preinstall finished (0)
    Installer-->>Developer: install finished

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Pay special attention to:
  • react_on_rails_pro/script/preinstall.js: detection of node_modules, command invocation/error handling, and choice to exit 0 on failure.
  • react_on_rails_pro/package.json: files array and preinstall script entry.
  • CONTRIBUTING.md: accuracy of example commands, ports, and linked URLs.

Possibly related PRs

• Fix generator tests #1706 — related local linking / yalc usage in install scripts.
• Enable use as a Git dependency #1664 — related changes enabling use as a Git dependency.

Suggested reviewers

• AbanoubGhadban
• Judahmeek
• justin808

Poem

🐰
I nudged a script from package.json’s nest,
and taught the installer how to do its best.
Docs now point where Git installs may play,
preinstall prances softly and hops away. 🥕✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title "Update preinstall script to enable use as a Git dependency" accurately describes a key technical change in the pull request. The preinstall script is indeed updated (moved from inline to a separate file and made more robust), and this change directly enables the use of react_on_rails_pro as a Git dependency as described in the PR objectives. The title is specific and clear enough that a developer scanning history would understand the primary technical change, even though the PR also includes supporting documentation updates to CONTRIBUTING.md and CHANGELOG.md. The title is not vague, misleading, or overly broad.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch alexeyr/fix-prepare-script

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Code Review: PR #1873 - Update preinstall script to enable use as a Git dependency

Summary

This PR refactors the preinstall script from inline shell commands to a dedicated Node.js script, enabling the package to work properly when installed as a Git dependency.

---

✅ Strengths

1. Code Quality

• Clean separation of concerns: Moving complex logic from package.json to a dedicated script improves maintainability
• Good error handling: The try-catch block gracefully handles failures without breaking the install process
• Cross-platform compatibility: Using Node.js instead of shell commands ensures Windows compatibility
• Clear intent: Comments explain the purpose and behavior well

2. Implementation

• Smart detection: The inNodeModules check (preinstall.js:7) correctly identifies when the package is being installed as a dependency
• Process control: Using spawnSync with stdio: 'inherit' properly streams output to the parent process
• Graceful degradation: Exit code 0 on failure ensures the install continues, which is appropriate for optional development tooling

---

🔍 Issues & Recommendations

Critical: Inconsistent Error Handling

Location: react_on_rails_pro/script/preinstall.js:14-18

The runCommand function throws errors on failure, but the catch block at line 26 catches them and exits with code 0. This creates inconsistent behavior where exceptions are used for control flow.

Recommendation: Since these commands are optional, consider removing the throws from runCommand and returning a boolean status instead. This makes the intent clearer and avoids using exceptions for control flow.

---

Minor: Edge Case - Missing __dirname

Location: preinstall.js:6

The fallback to process.cwd() is good defensive coding, but __dirname should always be defined in CommonJS scripts. This fallback might mask a real problem if __dirname is ever undefined.

Recommendation: Consider adding a comment explaining when this fallback would be needed, or remove it if it's unnecessary.

---

Minor: Error Object Logging

Location: preinstall.js:29

Logging the entire error object may produce unclear output. Consider logging just the message for better readability.

---

🔒 Security Considerations

✅ No security concerns identified

• No arbitrary code execution vulnerabilities
• No file system operations outside expected boundaries
• Proper use of spawnSync with explicit arguments (no shell injection)
• Script runs in development context only (not in production)

---

⚡ Performance Considerations

✅ Performance is appropriate

• Synchronous operations are acceptable for install scripts
• Early exit when inNodeModules === true avoids unnecessary work
• No blocking operations that would significantly impact install time

---

🧪 Test Coverage

⚠️ No tests provided

While install scripts are notoriously difficult to test, consider:

1. Manual testing documentation: Add a section to the PR description or CONTRIBUTING.md showing how to verify this works
2. Simple validation script: Create a test that verifies the script exists and has valid syntax

---

📝 Documentation

✅ PR description mentions documentation updates

• Consider adding a comment in package.json next to the preinstall script explaining its purpose
• Document the Git dependency use case in relevant docs if not already done

---

🎯 Final Recommendation

Approve with minor suggestions

The PR successfully solves the Git dependency installation issue with a clean, cross-platform solution. The main concerns are around code clarity and error handling patterns rather than functional issues.

Before merging:

1. ✅ Update error handling in runCommand to avoid throw/catch for control flow
2. ✅ Improve error logging clarity
3. ✅ Consider adding manual testing documentation
4. ⚠️ CRITICAL: Run bundle exec rubocop and ensure all files end with newlines (per CLAUDE.md requirements)
5. ⚠️ Verify Prettier formatting has been run on the new JavaScript file

Alignment with CLAUDE.md

• ✅ Cross-platform compatibility (no shell-specific commands)
• ⚠️ Verify Prettier formatting has been run
• ⚠️ Ensure the new file ends with a newline character

---

Great work on improving the developer experience for Git dependency usage! 🚀

[claude]

Code Review - PR #1873

Summary

This PR refactors the preinstall script to enable the react_on_rails_pro package to work as a Git dependency by moving the logic from a shell command string to a dedicated Node.js script.

---

Positive Aspects

1. Cross-platform compatibility: Converting from shell commands to Node.js using child_process.spawnSync makes this work on Windows, macOS, and Linux.

2. Smart detection logic: The inNodeModules check prevents the link steps from running when installed as a dependency, which is exactly what is needed for Git dependencies.

3. Graceful error handling: The try-catch block with process.exit(0) ensures that optional linking steps do not break installations when yalc or other tools are not available.

4. Preserves existing behavior: For local development, the script still runs the same link-source and yalc add commands.

---

Code Quality Issues

1. Missing newline at end of file - CRITICAL
   File: react_on_rails_pro/script/preinstall.js

The new file is missing a trailing newline character, which will cause CI to fail per the CLAUDE.md requirements.

Fix: Add a newline after the final closing brace on line 31.

2. Potential false positives in path detection
   File: react_on_rails_pro/script/preinstall.js:7

The check for node_modules could incorrectly match if someone has node_modules anywhere in their directory path.

Recommendation: Use a more robust check that looks for node_modules as a directory boundary.

3. Inconsistent directory reference
   File: react_on_rails_pro/script/preinstall.js:6

The fallback to process.cwd() is unnecessary since __dirname is always defined in regular Node.js scripts.

4. Error handling could be more specific
   File: react_on_rails_pro/script/preinstall.js:28-30

The generic error catch makes debugging harder. Consider adding more specific error information including the error message and code.

---

Testing Concerns

Issue: The PR checklist shows test coverage is not complete.

Recommendation: Consider adding tests for:

• Script behavior when run inside node_modules (should skip)
• Script behavior when run outside node_modules (should execute commands)
• Script behavior when yarn or yalc are not available (should gracefully exit)

---

Security Considerations

No security concerns identified. The script:

• Only runs commands specified in the codebase
• Does not accept external input
• Uses synchronous spawning (no shell injection risk)
• Has proper error boundaries

---

Performance Considerations

Performance impact is minimal:

• Script runs only during yarn install
• Uses synchronous operations (appropriate for install scripts)
• Early exit for node_modules case minimizes overhead

---

Additional Recommendations

1. Add execute permissions: Run chmod +x react_on_rails_pro/script/preinstall.js

2. Documentation: Consider updating the CONTRIBUTING.md to mention this change for users who might add this as a Git dependency.

3. Linting: Before committing, ensure you run bundle exec rubocop and rake autofix

---

Must Fix Before Merge

• CRITICAL: Add trailing newline to preinstall.js
• IMPORTANT: Run bundle exec rubocop and fix any violations
• RECOMMENDED: Improve node_modules detection logic

---

Overall Assessment

This is a well-intentioned change that solves a real problem (Git dependency support). The code structure is clean and the approach is sound. However, there are critical formatting issues that will cause CI to fail, and some edge cases in the detection logic that should be addressed.

Recommendation: Request changes to fix the critical formatting issue and improve the path detection logic before merging.

---

Review generated by Claude Code following repository conventions from CLAUDE.md

[claude]

Code Review: PR #1873

This PR successfully enables Git dependency support by refactoring the preinstall script. Overall assessment: Approve with minor suggestions

Strengths

1. Excellent architecture: Moving from inline shell commands to a dedicated Node.js script improves maintainability and cross-platform compatibility
2. Smart detection logic: The inNodeModules check elegantly skips link steps when installed as a dependency
3. Graceful error handling: Optional dev tooling failures don't break production installs
4. Comprehensive documentation: CONTRIBUTING.md now clearly documents all three testing methods (local, Git, tarball)

Issues & Recommendations

Minor: Node Modules Detection Edge Case

Location: preinstall.js:7

The check could produce false positives if 'node_modules' appears anywhere in the directory path. Consider using a more robust check that verifies node_modules is a direct parent directory.

Severity: Low

Minor: Redundant Fallback

Location: preinstall.js:6

The fallback to process.cwd() is unnecessary since __dirname is always defined in CommonJS modules.

Severity: Very Low

Code Style: Exception Control Flow

Location: preinstall.js:14-18, 26-31

The runCommand function throws errors which are then caught and ignored. Consider refactoring to return status objects instead.

Severity: Low (stylistic preference)

Security & Performance

• Security: No concerns identified. Proper use of spawnSync with explicit arguments prevents shell injection
• Performance: Appropriate for install scripts. Early exit avoids unnecessary work

CLAUDE.md Compliance

Before merging, verify:

1. CRITICAL: preinstall.js file ends with a newline character (will cause CI failure if missing)
2. IMPORTANT: Run rake autofix to ensure Prettier formatting
3. IMPORTANT: Run bundle exec rubocop and fix any violations
4. RECOMMENDED: Add manual testing notes to PR description

Impact Assessment

• Breaking changes: None
• Backward compatibility: Fully maintained
• Risk level: Low

Great work on improving the Git dependency support!

---

Review by Claude Code following CLAUDE.md conventions

[claude]

Pull Request Review: Update preinstall script to enable use as a Git dependency

Summary

This PR successfully enables React on Rails packages to be installed as Git dependencies, which is valuable for development and testing. The changes are well-documented and the implementation is thoughtful.

Code Quality & Best Practices

Strengths ✅

1. Excellent Documentation: The CONTRIBUTING.md updates are comprehensive and well-structured:

   • Clear separation of local, Git, and tarball dependency methods
   • Specific examples for different package managers (Yarn Berry, PNPM, NPM)
   • Practical examples that maintainers and contributors can follow

2. Smart Environment Detection: The preinstall.js script correctly detects whether it's running inside node_modules to avoid unnecessary operations:

   const inNodeModules = dir.split(path.sep).includes('node_modules');

3. Cross-Platform Compatibility: Uses Node.js built-in modules (path, child_process) ensuring it works across Windows, macOS, and Linux.

4. Graceful Degradation: The try-catch block with informative error logging ensures installations don't fail when optional link steps aren't available:

   catch (err) {
     console.error('preinstall: optional link steps failed or are unavailable — continuing.', err);
     process.exit(0);
   }

5. CHANGELOG Compliance: Properly documented in CHANGELOG.md with PR reference and attribution.

Areas for Improvement 🔍

1. Error Handling Specificity: The current error handling treats all failures the same way. Consider differentiating between:

   • Commands not found (expected in Git dependencies)
   • Actual execution failures (might need user attention)

   Suggestion:

   catch (err) {
     if (err.code === 'ENOENT') {
       console.log('preinstall: yalc not found — skipping local development setup (this is normal for Git dependencies).');
     } else {
       console.error('preinstall: optional link steps failed:', err.message);
     }
     process.exit(0);
   }

2. Minor Documentation Inconsistency:

   • CONTRIBUTING.md line 130 references port http://localhost:3000/
   • Previous content (line 125 from original) referenced http://localhost:5000/
   • Verify which port is actually used by the dummy app

Potential Bugs or Issues

Medium Priority

1. Race Condition Potential: The sequential runCommand calls could fail if the first command modifies the file system in a way that affects the second:

   runCommand('yarn', ['run', 'link-source']);  // publishes to yalc
   runCommand('yalc', ['add', '--link', 'react-on-rails']);  // consumes from yalc

   While unlikely to cause issues, consider adding a small delay or checking for completion.

2. Undefined __dirname in ES Modules: If this package ever migrates to ES modules, __dirname won't be available. Consider future-proofing:

   const dir = __dirname || process.cwd();

   Actually, this is already handled! Good defensive programming.

Performance Considerations

1. Unnecessary Work Avoided: ✅ The inNodeModules check prevents running expensive yalc operations when installed as a dependency.

2. Subprocess Overhead: The two runCommand calls spawn separate processes. This is acceptable given they only run during local development setup.

Security Concerns

Low Risk ✅

1. No User Input: The script doesn't accept user input, reducing injection attack surface.
2. Fixed Command Arguments: All command arguments are hardcoded arrays, preventing shell injection.
3. Standard Node.js APIs: Uses only built-in Node modules, no third-party dependencies.

Recommendations

1. Validate Command Existence: Consider checking if commands exist before execution to provide better error messages:

   function commandExists(cmd) {
     try {
       cp.execSync(`which ${cmd}`, { stdio: 'ignore' });
       return true;
     } catch {
       return false;
     }
   }

Test Coverage

Concerns ⚠️

1. No Automated Tests: The PR checklist shows:

   • Add/update test to cover these changes ❌

   Recommendation: Add integration tests that:

   • Verify the script runs successfully in node_modules
   • Verify the script skips operations when inside node_modules
   • Test error handling paths
   • Validate Git dependency installation works end-to-end

2. Manual Testing Needed: The changes should be manually tested:

   • Install from Git using Yarn Berry, PNPM (if possible), and as a tarball
   • Verify the Pro Node renderer works correctly when installed as a Git dependency
   • Test on Windows, macOS, and Linux

Additional Observations

1. Package Manager Coverage: The documentation now covers Yarn Berry and PNPM but correctly notes NPM's lack of support for Git subdirectory dependencies. This is accurate and helpful.

2. Consistency with Project Standards:

   • ✅ File ends with newline
   • ✅ Uses single quotes consistently
   • ✅ Follows existing code style
   • ⚠️ Should run bundle exec rubocop to verify no Ruby violations

Recommendations Summary

Must Do (Before Merge)

1. Verify the port number discrepancy in documentation (5000 vs 3000)
2. Run bundle exec rubocop to ensure Ruby code passes linting

Should Do (Before or After Merge)

1. Add integration tests for the preinstall script
2. Manually test Git dependency installation across platforms
3. Consider improving error message specificity

Nice to Have (Future Enhancement)

1. Add command existence checks for better error messages
2. Consider adding a small test app in CI that installs from Git to catch regressions

Conclusion

This is a high-quality PR that solves a real problem and is well-documented. The code is clean, cross-platform, and follows good defensive programming practices. The main gap is test coverage, which should be addressed either before or shortly after merge.

Recommendation: Approve with minor suggestions. The lack of automated tests is the only significant concern, but given the scope and the quality of the implementation, this can be addressed in a follow-up.

---

Review generated by Claude Code

[alexeyr-ci2]

A better long-term solution is to make react_on_rails_pro just another package in the workspace like packages/react-on-rails and packages/react-on-rails-pro, then the preinstall script can be removed.

[coderabbitai]

Actionable comments posted: 5

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

CONTRIBUTING.md (1)

109-117: Add language specifier to shell code block.

This fenced code block is also missing a language identifier.

-```
+```sh
 cd <React on Rails root>/packages/react-on-rails
 # Will send the updates to other folders - MUST DO THIS AFTER ANY CHANGES
 yalc push
 cd <your project root>
 
 # Will update from yalc
 yarn
-```
+```

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6a040ee and 57a325f.

📒 Files selected for processing (4)

• CHANGELOG.md (2 hunks)
• CONTRIBUTING.md (2 hunks)
• react_on_rails_pro/package.json (1 hunks)
• react_on_rails_pro/script/preinstall.js (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (3)

• CHANGELOG.md
• react_on_rails_pro/package.json
• react_on_rails_pro/script/preinstall.js

🧰 Additional context used

📓 Path-based instructions (1)

**/*.{js,jsx,ts,tsx,css,scss,json,yml,yaml,md}

📄 CodeRabbit inference engine (CLAUDE.md)

Prettier is the sole authority for formatting all non-Ruby files; never manually format them

Files:

• CONTRIBUTING.md

🪛 LanguageTool

CONTRIBUTING.md

[style] ~95-~95: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...led files yarn run build-watch ``` You need to do this once to make sure your app depe...

(REP_NEED_TO_VB)

---

[style] ~106-~106: Consider shortening or rephrasing this to strengthen your wording.
Context: ...eact-on-rails ``` The workflow is: 1. Make changes to the node package. 2. CRITICAL: Run ...

(MAKE_CHANGES)

---

[grammar] ~137-~137: Use a hyphen to join words.
Context: ...ing an update to the node package client side. Do the same for function `serverRe...

(QB_NEW_EN_HYPHEN)

🪛 markdownlint-cli2 (0.18.1)

CONTRIBUTING.md

97-97: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

109-109: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

165-165: Bare URL used

(MD034, no-bare-urls)

---

173-173: Bare URL used

(MD034, no-bare-urls)

---

181-181: Bare URL used

(MD034, no-bare-urls)

⏰ 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). (12)

• GitHub Check: rspec-package-tests (3.2, minimum)
• GitHub Check: rspec-package-tests (3.4, latest)
• GitHub Check: rspec-package-tests (3.2, latest)
• GitHub Check: rspec-package-tests (3.4, minimum)
• GitHub Check: build-dummy-app-webpack-test-bundles
• GitHub Check: build-dummy-app-webpack-test-bundles (3.4, 22)
• GitHub Check: markdown-link-check
• GitHub Check: build-dummy-app-webpack-test-bundles (3.2, 20)
• GitHub Check: build
• GitHub Check: claude-review
• GitHub Check: build-dummy-app-webpack-test-bundles
• GitHub Check: lint-js-and-ruby

🔇 Additional comments (1)

CONTRIBUTING.md (1)

52-134: Approve expanded testing documentation for Git dependencies and local workflows.

The restructured documentation comprehensively covers multiple testing approaches (local dependencies, Git dependencies, tarballs) with clear Ruby and JS-specific instructions. The port number updates (5000 → 3000), yalc workflow clarity, and practical examples like the NPM changes walkthrough (lines 135–139) are well-presented and should help contributors effectively test changes locally or via Git dependencies.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

CONTRIBUTING.md (2)

95-95: Optional style improvements flagged by static analysis.

Two minor suggestions for consideration:

• Line 95: The phrasing "You need to do this once" appears to have similar structure to nearby sentences (line 81). Consider varying the sentence structure for readability: "This step is only needed once to ensure your app depends on our package."

• Line 106: The instruction "Make changes to the node package" could be more concise: "Change the node package" or "Modify the node package."

These are stylistic suggestions and not correctness issues.

Also applies to: 106-106

---

181-181: Minor readability consideration for the npm link (line 181).

The current markdown format [Explicitly doesn't want to support it.](url) makes the entire sentence the link text. For consistency with the other links in this section and improved readability, consider restructuring it:

-[Explicitly doesn't want to support it.](https://github.com/npm/cli/issues/6253)
+Explicitly doesn't want to support it: [see issue](https://github.com/npm/cli/issues/6253)

This maintains the link while using more conventional markdown formatting and making the link text more descriptive.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 57a325f and 4d6458f.

📒 Files selected for processing (2)

• CHANGELOG.md (2 hunks)
• CONTRIBUTING.md (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• CHANGELOG.md

🧰 Additional context used

📓 Path-based instructions (1)

**/*.{js,jsx,ts,tsx,css,scss,json,yml,yaml,md}

📄 CodeRabbit inference engine (CLAUDE.md)

Prettier is the sole authority for formatting all non-Ruby files; never manually format them

Files:

• CONTRIBUTING.md

🪛 LanguageTool

CONTRIBUTING.md

[style] ~95-~95: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...led files yarn run build-watch ``` You need to do this once to make sure your app depe...

(REP_NEED_TO_VB)

---

[style] ~106-~106: Consider shortening or rephrasing this to strengthen your wording.
Context: ...eact-on-rails ``` The workflow is: 1. Make changes to the node package. 2. CRITICAL: Run ...

(MAKE_CHANGES)

⏰ 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). (10)

• GitHub Check: claude-review
• GitHub Check: build-dummy-app-webpack-test-bundles
• GitHub Check: build
• GitHub Check: rspec-package-tests (3.2, latest)
• GitHub Check: lint-js-and-ruby
• GitHub Check: rspec-package-tests (3.4, latest)
• GitHub Check: rspec-package-tests (3.2, minimum)
• GitHub Check: rspec-package-tests (3.4, minimum)
• GitHub Check: build-dummy-app-webpack-test-bundles
• GitHub Check: markdown-link-check

🔇 Additional comments (1)

CONTRIBUTING.md (1)

52-182: Excellent work addressing all past review feedback.

All critical issues from previous reviews have been resolved:

• Bare URLs are now properly wrapped in markdown links (lines 165, 173, 181)
• Compound adjective hyphenation corrected: "client-side" (line 137)
• Code blocks include language specifiers throughout

The reorganization substantially improves the documentation by clearly separating testing approaches (local, Git dependencies, tarball) and providing comprehensive examples for each. The new section structure makes it easier for contributors to find relevant guidance.