-
Notifications
You must be signed in to change notification settings - Fork 377
Enable Shakapacker early hints #687
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
base: master
Are you sure you want to change the base?
Conversation
|
Warning Rate limit exceeded@justin808 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 2 minutes and 13 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (4)
WalkthroughThis PR updates shakapacker from beta to stable (9.3.0), introduces the Thruster HTTP/2 proxy gem, and modifies deployment configurations across multiple Procfile variants and Docker setup to launch Rails via Thruster. Supporting changes include Shakapacker early hints configuration, comprehensive documentation, and a UI update acknowledging the technology stack. Changes
Sequence DiagramsequenceDiagram
participant Browser
participant Thruster as Thruster<br/>(HTTP/2 Proxy)
participant Rails as Rails Server<br/>(HTTP/1.1)
participant Shakapacker
Browser->>Thruster: Request (HTTP/2)
Note over Thruster: HTTP/2 Multiplexing<br/>Early Hints<br/>Asset Caching
Thruster->>Rails: Request (HTTP/1.1)
Rails->>Shakapacker: Asset Request
Shakapacker-->>Rails: Asset Response
Rails-->>Thruster: Response
Note over Thruster: Compress (Brotli)<br/>Add Link Headers<br/>TLS Termination
Thruster-->>Browser: Response (HTTP/2)
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes
Areas requiring attention:
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
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 |
|
/deploy-review-app |
🚀 Quick Review App CommandsWelcome! Here are the commands you can use in this PR:
|
PR Review: Enable Shakapacker Early HintsThank you for this PR! Here's my comprehensive review: SummaryThis PR enables HTTP/2 early hints support by updating dependencies to use the Code Quality & Best PracticesGood:
Concerns:
Potential Bugs & Issues
Performance ConsiderationsPositive:
Considerations:
Security ConcernsLow Risk Changes:
Recommendations:
Test CoverageCurrent State:
Recommendations:
Additional Recommendations
Action Items Before Merge
Overall AssessmentVerdict: Needs revision before merge The concept and implementation approach are sound, but there are several concerns that should be addressed:
Once these items are addressed, this should be a valuable performance improvement! Let me know if you need help with any of these recommendations. |
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)
config/shakapacker.yml (1)
67-69: Add context and rationale for the early_hints configuration.The configuration enables early hints for production, which is aligned with the PR objective. However, the comment is minimal. Consider adding more detail:
- Explain what HTTP/2 Early Hints does (preloading critical resources)
- Note any performance or compatibility considerations
- Reference any related documentation or issues
Current implementation looks correct; this is a documentation enhancement request.
Consider updating the comment as follows:
# Cache manifest.json for performance cache_manifest: true # Early hints configuration # HTTP/2 Early Hints allows the server to proactively push resources # that the client is likely to need, improving perceived performance. # Requires HTTP/2 support and compatible browser/client. early_hints: enabled: true
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
Gemfile.lockis excluded by!**/*.lockyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (3)
Gemfile(1 hunks)config/shakapacker.yml(1 hunks)package.json(1 hunks)
🔇 Additional comments (3)
Gemfile (2)
6-6: Clarify the reason for downgrading Ruby from 3.4.6 to 3.4.3.This is a patch-version downgrade without explanation. Confirm whether this is:
- A required dependency constraint from the new Shakapacker branch
- A security or compatibility fix
- An intentional change with a specific reason
If unintentional or not required, consider reverting to 3.4.6.
9-9: Feature branch is under active development, but dependency risks remain.The
justin808/early-hintsbranch exists and is actively maintained (last commit verified Oct 17, 2025). Issues #721–#722 for Early Hints support were opened Oct 14, 2025, indicating intentional ongoing development. However, using an unreleased feature branch in production dependencies poses real risks:
- Non-deterministic builds: Branch can change without notice; successive deployments may pull different code.
- Incomplete feature: Early Hints is not yet released in any stable Shakapacker version (latest: 8.3.0, April 2025).
- No guarantees: Unvetted development code may introduce breaking changes, security issues, or be abandoned.
If this is intentional for temporary testing, explicitly document the temporal nature and plan for either pinning to a specific commit hash or awaiting an official release. Otherwise, consider reverting to a stable released version.
package.json (1)
95-95: Confirm intentionality of branch-based dependency and align Gemfile and package.json if upgrading.Both Gemfile and package.json consistently use
shakacode/shakapacker#justin808/early-hints, which currently resolves to version9.3.0.beta.2. While stable releases exist (9.1.0,9.2.0), the branch-based approach does introduce production risks: non-deterministic builds, unvetted pre-release code, and branch-dependent maintenance.Verify that this branch-based approach is intentional for the early-hints feature development. If migrating to a released version, update both files together to maintain consistency across your dependency management.
Updated Ruby version from 3.4.3 to 3.4.6 to match CI environment expectations. This fixes the bundle install failure in GitHub Actions. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
PR Review: Enable Shakapacker early hintsI've reviewed this PR and here's my comprehensive feedback: Overall AssessmentThis is a clean and focused PR that enables HTTP/2 Early Hints support for asset preloading. The changes are well-scoped and follow a logical pattern. Code Quality and Best PracticesStrengths:
Recommendations:
Performance ConsiderationsPositive Impact:Early Hints is excellent for performance:
Important Requirements:HTTP/2 Support Required:
Action Required:
Potential Bugs or IssuesCritical: Compatibility Check Needed
Security ConcernsLow Risk:
Considerations:
Test CoverageMissing Tests:Currently, there are no tests included for this feature. This is concerning for a production configuration change. Recommended Test Coverage:
Action Items SummaryBefore Merging:
Nice to Have:
ConclusionThis is a good quality PR with clear intent and clean implementation. The Early Hints feature should provide meaningful performance improvements for users on HTTP/2 connections. Main concerns:
Recommendation: Approve with conditions - Address the HTTP/2 verification and testing checklist before deploying to production. Great work on keeping the changes focused and well-organized! |
When installing shakapacker from a GitHub branch, the TypeScript source needs to be compiled. Added a postinstall script that: 1. Detects if shakapacker was installed from source (has .ts but no .js files) 2. Installs shakapacker's dev dependencies 3. Runs the build script to compile TypeScript to JavaScript This ensures the package is properly built even when installed directly from GitHub instead of npm. Also updated shakapacker reference to use explicit github: prefix for clarity. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
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: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (1)
package.json(2 hunks)
🔇 Additional comments (2)
package.json (2)
20-20: Verify the postinstall build produces the expected shakapacker bundle.The conditional build logic assumes that building shakapacker in
node_moduleswill produce a functional bundle. Confirm that:
- The
yarn buildstep in shakapacker completes successfully- The resulting
index.jsis actually generated and usable by the asset pipeline- No build artifacts are missing or corrupted
Test this locally on both Mac/Linux and Windows (or WSL) by running
yarn installand verifying the bundle integrity.
95-95: <!-- [scratchpad]
[task review_dependency_pinning 1/1]
Verify concerns about shakapacker branch pinning.[observations]
- Repository: react-webpack-rails-tutorial (by shakacode)
- Dependency: "shakapacker": "github:shakacode/shakapacker#justin808/early-hints"
- Branch justin808/early-hints is ACTIVE and recently updated (Oct 17, 2025)
- Latest commit: 6bf6bf5
- postinstall script present: builds shakapacker from source if needed
- yarn.lock is committed (visible from script output)
- Only GitHub dependency in package.json
- Recent commit message: "Add postinstall script to build shakapacker from GitHub branch"
[analysis]
- Review comment is technically correct: branch refs are mutable, commits are more reproducible
- HOWEVER: Context matters significantly here
- This is a tutorial repo testing an unreleased feature from upstream shakapacker
- postinstall script + committed yarn.lock already provide reproducibility guarantees
- The branch reference is intentional, not accidental
- This is a legitimate pattern for feature-branch testing before stable release
- Pinning to commit 6bf6bf5 would actually be worse if developers want to test updates
[conclusion]
Review comment's concern is valid but overly rigid for this development/testing scenario. The current setup mitigates the stated risks through:
- Committed yarn.lock (deterministic installs)
- postinstall build script (explicit build process)
- Active upstream maintenance
The developer should make an informed decision about whether this temporary feature-branch reference aligns with their project's dependency strategy.[done]
Verification complete. This is not an error or broken practice—it's an intentional development setup that requires developer confirmation of intent.
</scratchpad]Confirm whether pinning shakapacker to the feature branch is intentional and acceptable for your project's current development phase.
The review comment's concern about branch mutability is technically valid; however, your setup already mitigates the key reproducibility risks:
- yarn.lock is committed, making installs deterministic
- postinstall script builds shakapacker from source, showing deliberate integration testing
- Branch justin808/early-hints is active and maintained (latest commit: 6bf6bf5, updated Oct 17, 2025)
This is a legitimate pattern for testing unreleased features from an upstream branch before a stable release. If you plan to stay on this branch temporarily while testing early-hints, the current approach is acceptable. However, you should:
- Document in a comment why this branch reference exists (e.g., "TODO: pin to shakapacker release once early-hints merges")
- Plan to upgrade to a stable shakapacker release once the feature ships
- If you want extra safety now, pin to the specific commit (
#6bf6bf5) with a comment explaining it's temporary
🎉 ✨ Deploy Complete! 🚀🌐 ➡️ Open Review AppDeployment successful for PR #687, commit 9fca254 🎮 Control Plane Console |
Pull Request Review: Enable Shakapacker Early HintsThank you for this PR! I've reviewed the changes to enable early hints support in Shakapacker. Here's my detailed feedback: ✅ Code Quality & Best PracticesStrengths:
Concerns:
🐛 Potential Bugs & Issues
⚡ Performance ConsiderationsPositive Impacts:
Potential Issues:
🔒 Security Concerns
🧪 Test CoverageCurrent State:
Recommendations:
📝 Additional Recommendations
🎯 SummaryOverall Assessment: This is a well-intentioned performance optimization with clean implementation. However, it needs additional validation and testing before production deployment. Recommendation: Request Changes Required Before Merge:
Nice to Have:
Files Changed Review:
Great work on exploring performance optimizations! Please address the testing and documentation concerns before merging. Review generated with assistance from Claude Code |
Updated Gemfile.lock and yarn.lock to pick up the latest changes from the shakapacker justin808/early-hints branch. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
🎉 ✨ Deploy Complete! 🚀🌐 ➡️ Open Review AppDeployment successful for PR #687, commit eb1b3be 🎮 Control Plane Console |
Pull Request Review: Enable Shakapacker Early HintsOverviewThis PR updates the project to use a development branch of Shakapacker that includes early hints support, and enables the early hints feature in production. The changes are focused on dependency updates and configuration. Code Quality & Best Practices✅ Strengths
|
Add debug: true to early hints configuration to output debug info as HTML comments in production, making it easier to verify that early hints are working correctly. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
🎉 ✨ Deploy Complete! 🚀🌐 ➡️ Open Review AppDeployment successful for PR #687, commit 9930aaf 🎮 Control Plane Console |
Pull Request Review: Enable Shakapacker Early HintsThank you for this PR! I've reviewed the changes to enable early hints support via the shakapacker branch. Here's my detailed feedback: ✅ Positive Aspects
🔍 Code Quality & Best Practices1. PostInstall Script (package.json:20)The postinstall script has grown quite complex. This one-liner is hard to read and maintain. Concerns:
Recommendations:
2. Branch Dependency ManagementUsing a GitHub branch as a dependency is appropriate for testing/preview, but: Concerns:
Recommendations:
3. Early Hints Configuration (config/shakapacker.yml:67-70)The configuration looks good, but could use more documentation. Recommendations:
🐛 Potential Issues1. Ruby Version Change (Gemfile.lock)I noticed the Ruby version patch changed from 3.4.6p32 to 3.4.6p54. This appears to be an unintentional side effect rather than a deliberate change. Impact: Low - same minor/patch version 2. Yarn.lock ChangesThe yarn.lock shows all resolved URLs changed format. This is cosmetic but suggests a potential yarn version inconsistency. Recommendation: Ensure all developers are using the same yarn version (currently specified as 1.22.22 in package.json) 🔒 Security Considerations1. Branch Dependency Security✅ Good: Using a specific commit in the lock file provides reproducible builds Recommendations:
2. Build Script ExecutionThe postinstall script runs arbitrary build commands from a third-party package. Impact: Low (trusted source - shakacode) ⚡ Performance Considerations1. Install TimeThe postinstall script conditionally builds shakapacker from source, which:
Recommendations:
2. Early Hints Benefits✅ This is the whole point of the PR! Early hints should provide measurable performance improvements. Recommendations:
🧪 Testing & VerificationThe PR description has a testing checklist, which is great! However: Missing Test Coverage:
Recommendations:
📋 SummaryOverall Assessment: This is a solid PR with a clear purpose and systematic implementation. The main concerns are around the complexity of the postinstall script and the temporary nature of using a branch dependency. Priority Recommendations:
Approval Status: Great work on improving the application's performance! Let me know if you'd like help implementing any of these suggestions. |
Refreshed Gemfile.lock and yarn.lock to pull in the latest changes from shakapacker's justin808/early-hints branch. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
🎉 ✨ Deploy Complete! 🚀🌐 ➡️ Open Review AppDeployment successful for PR #687, commit 395b7a4 🎮 Control Plane Console |
|
PR Review: Enable Shakapacker Early Hints Overview: This PR enables HTTP/2 early hints support in Shakapacker to improve perceived page load performance by allowing the server to send link headers early in the response lifecycle. Code Quality - Positive aspects:
Suggestions:
Potential Issues:
Performance Considerations: Positive:
Considerations:
Security Concerns (Overall: Low Risk):
Test Coverage Concerns:
Additional Recommendations:
Summary: Verdict: Approve with minor suggestions This PR is well-structured and implements a useful performance feature. The main concerns are:
Before merging:
After merging:
Great work on improving performance! |
Pull Request Review: Enable Shakapacker Early HintsOverviewThis PR integrates Thruster HTTP/2 proxy and enables early hints support in Shakapacker. This is a significant infrastructure improvement with excellent documentation. Overall quality is very high. ✅ Strengths1. Excellent Documentation
2. Transparent About Limitations
3. Proper Infrastructure Setup
|
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
♻️ Duplicate comments (3)
client/app/bundles/comments/components/Footer/ror_components/Footer.jsx (2)
22-72: Extract repeated SVG checkmark icons to reduce duplication.Three nearly identical checkmark SVG icons are repeated throughout this section (lines 22-28, 44-50, 66-72), differing only in color and size. This violates DRY principles and makes maintenance harder.
Extract to a reusable component:
const CheckmarkIcon = ({ className = "w-4 h-4", color = "text-green-400" }) => ( <svg className={`${className} ${color}`} fill="currentColor" viewBox="0 0 20 20" aria-hidden="true" > <path fillRule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clipRule="evenodd" /> </svg> );Then replace the repeated SVGs:
<CheckmarkIcon className="w-4 h-4" color="text-green-400" /> <CheckmarkIcon className="w-3.5 h-3.5" color="text-emerald-400" />
73-83: Hardcoded deployment claim is misleading for multi-platform support.The footer claims "Hosted on Control Plane" but this application supports multiple deployment platforms (Heroku, VPS, Kubernetes) as documented in the README and Procfile variants. This hardcoded claim could mislead users deploying elsewhere.
Consider making this conditional based on environment detection:
-<span className="text-xs"> - Hosted on{' '} - <a - href="https://shakacode.controlplane.com" - className="text-blue-400 hover:text-blue-300 underline" - target="_blank" - rel="noopener noreferrer" - > - Control Plane - </a> -</span> +<span className="text-xs"> + Supports{' '} + <a + href="https://shakacode.controlplane.com" + className="text-blue-400 hover:text-blue-300 underline" + target="_blank" + rel="noopener noreferrer" + > + Control Plane + </a> + {' '}hosting +</span>Alternatively, make this configurable via an environment variable.
docs/thruster.md (1)
290-296: Document Shakapacker early hints configuration.The Shakapacker Integration section doesn't document the early hints configuration in
config/shakapacker.yml, which is a key objective of this PR (enabling Shakapacker early hints). This documentation gap makes it harder for users to understand the complete Thruster + Shakapacker integration.Add a subsection under "Shakapacker Integration":
### Shakapacker Integration Thruster works seamlessly with Shakapacker for both Webpack and Rspack: - Compiled assets in `public/packs/` are automatically cached - Manifest files are properly served - Hot Module Replacement (HMR) still works in development + +#### Early Hints Configuration + +Thruster works with Shakapacker's early hints feature to optimize asset loading: + +\`\`\`yaml +# config/shakapacker.yml +production: + early_hints: + enabled: true + debug: true +\`\`\` + +When enabled, Shakapacker emits Link headers for webpack assets, which browsers can use for preloading. Note that early hints require direct connection to the app server (see [Early Hints Investigation](./early-hints-investigation.md) for CDN limitations).
🧹 Nitpick comments (3)
client/app/bundles/comments/components/Footer/ror_components/Footer.jsx (1)
22-72: Add accessibility attributes to decorative SVG icons.All SVG icons in this section are decorative (supplementing adjacent text) but lack accessibility attributes, which can cause screen readers to announce unhelpful content.
Add
aria-hidden="true"to all decorative SVG elements:-<svg className="w-4 h-4 text-green-400" fill="currentColor" viewBox="0 0 20 20"> +<svg className="w-4 h-4 text-green-400" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true">Apply this to all SVG icons at lines 22, 44, 54, and 66.
docs/early-hints-investigation.md (1)
129-187: Minor formatting improvements for technical specifications.Static analysis suggests minor formatting improvements for consistency:
- - **Best case**: 100-200ms improvement on slow connections + - **Best case**: 100–200 ms improvement on slow connections- - Gain minimal performance benefit (<200ms in best case) + - Gain minimal performance benefit (<200 ms in best case)- - ✅ HTTP/2 capable server (Puma 5+, Thruster, nginx 1.13+) + - ✅ HTTP/2-capable server (Puma 5+, Thruster, nginx 1.13+)These changes improve technical writing clarity but are not critical.
docs/thruster.md (1)
44-281: Add language identifiers to fenced code blocks.Multiple fenced code blocks lack language identifiers (lines 44, 49, 54, 59, 64, 125, 137, 211, 276, 281), which prevents syntax highlighting and reduces readability.
Add appropriate language identifiers:
-``` +```text web: bundle exec thrust bin/rails serverApply to all Procfile snippets (use `text` or `procfile`) and shell output examples (use `text` or `console`). </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used**: CodeRabbit UI **Review profile**: CHILL **Plan**: Pro <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between eea187fec60e9855724657a60283e213514cfe1b and a4edfdb7638e7b8cac05d23fcf45e346060fe313. </details> <details> <summary>⛔ Files ignored due to path filters (1)</summary> * `Gemfile.lock` is excluded by `!**/*.lock` </details> <details> <summary>📒 Files selected for processing (7)</summary> * `.controlplane/readme.md` (1 hunks) * `.controlplane/templates/rails.yml` (1 hunks) * `.ruby-version` (1 hunks) * `Gemfile` (2 hunks) * `client/app/bundles/comments/components/Footer/ror_components/Footer.jsx` (1 hunks) * `docs/early-hints-investigation.md` (1 hunks) * `docs/thruster.md` (1 hunks) </details> <details> <summary>✅ Files skipped from review due to trivial changes (1)</summary> * .ruby-version </details> <details> <summary>🚧 Files skipped from review as they are similar to previous changes (2)</summary> * Gemfile * .controlplane/readme.md </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>🪛 LanguageTool</summary> <details> <summary>docs/early-hints-investigation.md</summary> [grammar] ~129-~129: Ensure spelling is correct Context: ...ered successfully: - **Best case**: 100-200ms improvement on slow connections - **Com... (QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1) --- [grammar] ~156-~156: Ensure spelling is correct Context: ...ent - Gain minimal performance benefit (<200ms in best case) **Cost-benefit analysis*... (QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1) --- [grammar] ~187-~187: Use a hyphen to join words. Context: ...st.send_early_hints` support) - ✅ HTTP/2 capable server (Puma 5+, Thruster, nginx... (QB_NEW_EN_HYPHEN) </details> </details> <details> <summary>🪛 markdownlint-cli2 (0.18.1)</summary> <details> <summary>docs/thruster.md</summary> 44-44: Fenced code blocks should have a language specified (MD040, fenced-code-language) --- 49-49: Fenced code blocks should have a language specified (MD040, fenced-code-language) --- 54-54: Fenced code blocks should have a language specified (MD040, fenced-code-language) --- 59-59: Fenced code blocks should have a language specified (MD040, fenced-code-language) --- 64-64: Fenced code blocks should have a language specified (MD040, fenced-code-language) --- 125-125: Fenced code blocks should have a language specified (MD040, fenced-code-language) --- 137-137: Fenced code blocks should have a language specified (MD040, fenced-code-language) --- 211-211: Fenced code blocks should have a language specified (MD040, fenced-code-language) --- 276-276: Fenced code blocks should have a language specified (MD040, fenced-code-language) --- 281-281: Fenced code blocks should have a language specified (MD040, fenced-code-language) </details> </details> </details> <details> <summary>⏰ 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). (1)</summary> * GitHub Check: claude-review </details> <details> <summary>🔇 Additional comments (2)</summary><blockquote> <details> <summary>.controlplane/templates/rails.yml (1)</summary><blockquote> `23-24`: **LGTM! Clear documentation for Thruster protocol configuration.** These comments correctly explain why the protocol should remain `http` despite Thruster handling HTTP/2 on the TLS frontend. This clarification prevents configuration errors (502 protocol errors) that could occur from setting `protocol: http2`. </blockquote></details> <details> <summary>docs/early-hints-investigation.md (1)</summary><blockquote> `1-252`: **Excellent comprehensive documentation of Early Hints investigation.** This document provides thorough analysis of the Early Hints feature, correctly identifies the CDN limitation as root cause, and offers well-reasoned recommendations. The structure (executive summary, evidence, root cause, recommendations) makes it easy to understand both the technical details and practical implications. </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
Revert Ruby version from 3.4.3 back to 3.4.6 to match CI configuration. The CI workflows use Ruby 3.4.6, so Gemfile and .ruby-version must match. Changes: - Revert .ruby-version to 3.4.6 - Revert Gemfile ruby requirement to 3.4.6 - Regenerate Gemfile.lock with correct Ruby version This fixes the CI failures: ``` Your Ruby version is 3.4.6, but your Gemfile specified 3.4.3 ##[error]The process '/opt/hostedtoolcache/Ruby/3.4.6/x64/bin/bundle' failed with exit code 18 ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Update RUBY VERSION in Gemfile.lock from 3.4.3p32 to 3.4.6p62 to match the Ruby version specified in Gemfile and .ruby-version. This fixes the CI error: ``` Bundler is unlocking ruby, but the lockfile can't be updated because frozen mode is set ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
🎉 ✨ Deploy Complete! 🚀🌐 ➡️ Open Review AppDeployment successful for PR #687, commit 4ad6d60 🎮 Control Plane Console |
Pull Request Review: Enable Shakapacker Early HintsSummary✅ APPROVED - Excellent PR ready to merge with minor optional suggestions. Strengths1. Outstanding Documentation 📚
2. Production-Ready Configuration 🚀
3. Transparent Communication 💬
4. Performance Improvements ⚡
5. Security Best Practices 🔒
Minor Suggestions (Optional)1. Ruby Version Consistency 🟡 2. Test Coverage 🟡
3. Accessibility 🟡 4. Debug Mode 🟡 Code Quality AnalysisConfig Files: ✅ All correct
Frontend: ✅ Clean implementation
Dependencies: ✅ Clean upgrade
Verdict✅ APPROVED This PR demonstrates exceptional engineering:
The early hints investigation document alone is valuable for the community. The "Key Learnings" in .controlplane/readme.md will prevent future mistakes. Recommendation: Merge now, optionally add tests in follow-up PR. Great work! 🎉 Review based on code analysis, security scan, performance validation, and best practices assessment. |
Pull Request Review: Enable Shakapacker Early HintsSummaryThis PR successfully integrates Thruster HTTP/2 proxy and Shakapacker early hints to improve application performance. The implementation is well-documented, properly configured, and production-ready. Overall, this is a high-quality PR with excellent documentation. ✅ Strengths1. Excellent DocumentationThe PR includes exceptional documentation that will be invaluable for future maintainers:
2. Proper Dependency Management
3. Correct ConfigurationThe PR correctly configures Shakapacker early hints, Docker command, and Control Plane settings. Configuration is production-ready. 4. Transparent About LimitationsThe PR honestly documents that early hints don't reach end users due to Cloudflare CDN stripping HTTP 103 responses. The Footer component reflects this reality with accurate status indicators. 🔍 Code Quality ReviewFooter Component SuggestionsMinor Accessibility Improvements:
Positive:
🔒 Security Review: ✅ No Issues Found
⚡ Performance ConsiderationsExpected Improvements ✅
Monitoring Recommendations
🧪 Test Coverage:
|
Added comprehensive documentation for verifying HTTP 103 Early Hints: ## New Documentation ### docs/verify-early-hints-manual.md Complete guide for manually verifying early hints using browser DevTools: - Chrome DevTools Network tab inspection - Firefox Developer Tools (better 103 support) - curl debugging techniques - HAR file export and analysis - Expected vs actual results - Troubleshooting common issues - Comparison between Cloudflare and direct Control Plane Key verification methods: - Look for HTML debug comments confirming Rails sent 103 - Check Network waterfall for early asset loading - Inspect Link headers with rel=preload - Search for status 103 in HAR exports ### docs/chrome-mcp-server-setup.md Guide for enabling browser automation via MCP server: - What the Chrome MCP server provides - Setup methods (extension, debugging port, local process) - Troubleshooting connection issues - Alternative solutions using Playwright - Contact information for Conductor support Includes ready-to-use Playwright script for programmatic verification of HTTP 103 responses. ## Why These Guides? While curl shows HTML debug comments proving Rails sends early hints, browser-level verification is needed to confirm: 1. 103 responses actually reach the client 2. Browsers use them to preload assets 3. Performance benefit is measurable These guides enable manual verification until Chrome MCP server is operational for automated browser inspection. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
🎉 ✨ Deploy Complete! 🚀🌐 ➡️ Open Review AppDeployment successful for PR #687, commit b1af166 🎮 Control Plane Console |
Pull Request Review: Thruster HTTP/2 and Early Hints IntegrationSummaryThis PR successfully integrates Thruster HTTP/2 proxy and Early Hints support across the application. The implementation is well-executed with comprehensive documentation and proper configuration. Strengths1. Excellent Documentation
2. Consistent Configuration
3. Proper Infrastructure Setup
4. Realistic Expectations
Code Quality ObservationsGood Practices
Minor Considerations1. Missing Version Pin on Thruster Gem (Low Priority) 2. Footer Component: Hardcoded Feature Badges (Low Priority) 3. Repeated SVG Icons (Code Quality) Security Assessment - No Concerns Identified
Potential Bugs - None IdentifiedThe implementation is solid:
Performance ConsiderationsExpected ImprovementsBased on the documentation and Thruster capabilities:
Early Hints Reality
This is well-documented in docs/early-hints-investigation.md with evidence from production testing. Test CoverageCurrent State
RecommendationsConsider adding integration tests for:
Priority: Low - This is infrastructure change, not business logic. Manual testing via deployment is acceptable. Overall AssessmentCode Quality: 5/5
Security: 5/5
Performance: 5/5
Test Coverage: 3/5
Recommendation: APPROVEThis PR is ready to merge. The implementation is solid, well-documented, and follows best practices. The honest assessment of Early Hints limitations (CDN stripping HTTP 103) demonstrates good engineering judgment. The real performance benefits come from HTTP/2 multiplexing and Thruster asset optimization, which are properly configured. Merge Confidence: HighThe changes are:
Great work on this integration! Reviewed by: Claude Code |
…es (#1974) ## Summary This PR adds a `/run-skipped-ci` command that can be used in PR comments to trigger the complete CI suite, including tests that are normally skipped on PRs for faster feedback. It also fixes several workflow issues identified during development. ## What Changed **New GitHub Actions Workflows:** - `.github/workflows/run-skipped-ci.yml` - Listens for `/run-skipped-ci` comments and triggers all CI workflows with verification - `.github/workflows/pr-welcome-comment.yml` - Automatically comments on new PRs explaining the command **New Documentation:** - `.github/README.md` - Comprehensive documentation of all workflows and the comment command feature **Workflow Fixes:** - Fixed duplicate `if` conditions in `examples.yml` and `main.yml` that caused YAML parsing errors - Replaced inefficient `SKIP_MINIMUM_ON_PR` env var pattern with cleaner matrix-level `exclude` approach - Added workflow verification logic to confirm triggered workflows actually start - Improved error handling with detailed status reporting (verified/pending/failed workflows) ## How It Works 1. **Default PR behavior** - Runs subset of CI (latest Ruby/Node only) for fast feedback 2. **Full CI on demand** - Comment `/run-skipped-ci` on any PR to run: - Main test suite with all Ruby/Node version combinations - Example generator tests - Pro package integration tests - Pro package unit tests 3. **User feedback** - Bot reacts with 🚀, waits 5 seconds for workflows to queue, verifies they started, and posts detailed status ## Why This Approach By default, PRs run a limited CI suite to keep feedback loops fast: - Only latest versions (Ruby 3.4, Node 22, Shakapacker 9.3.0, React 19) - Skips minimum versions (Ruby 3.2, Node 20, Shakapacker 8.2.0, React 18) Before merging, we want to verify compatibility across all supported versions. This command makes it easy to run full CI without: - Waiting for merge to master - Manually triggering individual workflows - Modifying workflow files ## Technical Improvements ### Matrix Filtering Before: ```yaml env: SKIP_MINIMUM_ON_PR: ${{ matrix.dependency-level == 'minimum' && ... }} steps: - uses: actions/checkout@v4 if: env.SKIP_MINIMUM_ON_PR != 'true' # ❌ Step-level conditional ``` After: ```yaml matrix: include: [...] exclude: # ✅ Job-level filtering - more efficient - ruby-version: ${{ ... && '3.2' || '' }} dependency-level: ${{ ... && 'minimum' || '' }} ``` ### Workflow Verification The `/run-skipped-ci` command now: 1. Triggers all workflows via API 2. Waits 5 seconds for workflows to queue 3. Queries GitHub Actions API to verify workflows started 4. Reports detailed status showing which workflows are verified, pending, or failed ## Testing Notes **Important:** The comment-triggered workflow must be merged to `master` before it can be tested, because GitHub Actions only executes `issue_comment` workflows from the default branch (security feature). Once merged, test by: 1. Creating a test PR 2. Commenting `/run-skipped-ci` 3. Verifying all workflows trigger and status is reported accurately ## Inspiration Based on similar pattern from shakacode/react-webpack-rails-tutorial#687 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- Reviewable:start --> - - - This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/shakacode/react_on_rails/1974) <!-- Reviewable:end --> --------- Co-authored-by: Claude <noreply@anthropic.com>
…es (#1974) ## Summary This PR adds a `/run-skipped-ci` command that can be used in PR comments to trigger the complete CI suite, including tests that are normally skipped on PRs for faster feedback. It also fixes several workflow issues identified during development. ## What Changed **New GitHub Actions Workflows:** - `.github/workflows/run-skipped-ci.yml` - Listens for `/run-skipped-ci` comments and triggers all CI workflows with verification - `.github/workflows/pr-welcome-comment.yml` - Automatically comments on new PRs explaining the command **New Documentation:** - `.github/README.md` - Comprehensive documentation of all workflows and the comment command feature **Workflow Fixes:** - Fixed duplicate `if` conditions in `examples.yml` and `main.yml` that caused YAML parsing errors - Replaced inefficient `SKIP_MINIMUM_ON_PR` env var pattern with cleaner matrix-level `exclude` approach - Added workflow verification logic to confirm triggered workflows actually start - Improved error handling with detailed status reporting (verified/pending/failed workflows) ## How It Works 1. **Default PR behavior** - Runs subset of CI (latest Ruby/Node only) for fast feedback 2. **Full CI on demand** - Comment `/run-skipped-ci` on any PR to run: - Main test suite with all Ruby/Node version combinations - Example generator tests - Pro package integration tests - Pro package unit tests 3. **User feedback** - Bot reacts with 🚀, waits 5 seconds for workflows to queue, verifies they started, and posts detailed status ## Why This Approach By default, PRs run a limited CI suite to keep feedback loops fast: - Only latest versions (Ruby 3.4, Node 22, Shakapacker 9.3.0, React 19) - Skips minimum versions (Ruby 3.2, Node 20, Shakapacker 8.2.0, React 18) Before merging, we want to verify compatibility across all supported versions. This command makes it easy to run full CI without: - Waiting for merge to master - Manually triggering individual workflows - Modifying workflow files ## Technical Improvements ### Matrix Filtering Before: ```yaml env: SKIP_MINIMUM_ON_PR: ${{ matrix.dependency-level == 'minimum' && ... }} steps: - uses: actions/checkout@v4 if: env.SKIP_MINIMUM_ON_PR != 'true' # ❌ Step-level conditional ``` After: ```yaml matrix: include: [...] exclude: # ✅ Job-level filtering - more efficient - ruby-version: ${{ ... && '3.2' || '' }} dependency-level: ${{ ... && 'minimum' || '' }} ``` ### Workflow Verification The `/run-skipped-ci` command now: 1. Triggers all workflows via API 2. Waits 5 seconds for workflows to queue 3. Queries GitHub Actions API to verify workflows started 4. Reports detailed status showing which workflows are verified, pending, or failed ## Testing Notes **Important:** The comment-triggered workflow must be merged to `master` before it can be tested, because GitHub Actions only executes `issue_comment` workflows from the default branch (security feature). Once merged, test by: 1. Creating a test PR 2. Commenting `/run-skipped-ci` 3. Verifying all workflows trigger and status is reported accurately ## Inspiration Based on similar pattern from shakacode/react-webpack-rails-tutorial#687 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- Reviewable:start --> - - - This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/shakacode/react_on_rails/1974) <!-- Reviewable:end --> --------- Co-authored-by: Claude <noreply@anthropic.com>
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
The PR review app should use the same server as production to accurately test early hints behavior. Master uses Puma directly, not Thruster. Puma supports HTTP/1.1 103 Early Hints as documented in Shakapacker. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Added comprehensive explanation of curl's limitation with 1xx informational responses and how to properly verify early hints are working. Key findings: - curl verbose mode doesn't display 1xx informational responses - HTML debug comments prove Rails sends HTTP 103 - Browsers receive and use early hints even if curl doesn't show them - Use browser DevTools for actual verification Includes multiple verification methods and comparison between direct Control Plane vs Cloudflare proxy behavior. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Pull Request Review: Enable Shakapacker Early HintsSummaryThis PR adds HTTP/2 support via Thruster and configures Early Hints in Shakapacker. The implementation is technically sound and includes excellent documentation. However, there are some considerations around the actual effectiveness of Early Hints in production. Overall AssessmentRating: ✅ Approve with minor suggestions The code quality is high, configuration changes are appropriate, and the comprehensive documentation demonstrates thorough research. The PR author clearly understands the limitations (CDN stripping HTTP 103) and has documented this transparently. Code Quality & Best Practices✅ Strengths
🔸 Suggestions
Potential Bugs & Issues
|
Pull Request Review - PR #687: Early Hints and Thruster IntegrationSummaryThis PR integrates Thruster HTTP/2 proxy and configures Shakapacker 9.3.2 for Early Hints support. Well-documented with comprehensive investigation into CDN limitations. Code Quality: ✅ GOOD
Critical Issue:
|
Pull Request Review: Thruster HTTP/2 and Early Hints IntegrationOverviewThis PR integrates Thruster HTTP/2 proxy and configures HTTP 103 Early Hints support. The changes include dependency updates, infrastructure configuration, comprehensive documentation, and UI updates. Overall, this is a well-executed integration with excellent documentation. ✅ Strengths1. Excellent DocumentationThe PR includes exceptionally thorough documentation:
The documentation demonstrates deep understanding of the infrastructure and will be invaluable for future maintainers. 2. Honest Technical AssessmentThe PR doesn't oversell the benefits. It clearly documents that:
This transparency is commendable and prevents future confusion. 3. Clean Dependency Management
4. Comprehensive Procfile UpdatesAll Procfiles consistently updated to use Thruster:
5. User-Facing TransparencyThe Footer component (client/app/bundles/comments/components/Footer/ror_components/Footer.jsx:19-85) clearly indicates:
This is great UX that educates users about the infrastructure.
|
Changes
Gemfileto point toshakapackerfrom thejustin808/early-hintsbranch.package.jsonto useshakapackerfrom thejustin808/early-hintsbranch.early_hintsinconfig/shakapacker.ymlfor the production environment.Testing
This change is
Summary by CodeRabbit
Release Notes
New Features
Chores
Documentation
Results when