Skip to content

Update bin/shakapacker to auto-generate packs#1630

Merged
justin808 merged 1 commit intomasterfrom
justin808/misc-fixes
Jun 12, 2024
Merged

Update bin/shakapacker to auto-generate packs#1630
justin808 merged 1 commit intomasterfrom
justin808/misc-fixes

Conversation

@justin808
Copy link
Copy Markdown
Member

@justin808 justin808 commented Jun 12, 2024

This change is Reviewable

Summary by CodeRabbit

  • Chores

    • Added the debug gem to improve debugging capabilities during development and testing.
  • Enhancements

    • Improved the wp-server command for better environment variable handling.
    • Updated shakapacker script to optimize pack generation before compilation.
    • Enhanced shakapacker-dev-server to recommend pack generation before running the development server.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Jun 12, 2024

Walkthrough

The changes primarily focus on enhancing the development environment setup by adding the debug gem for better debugging capabilities and improving the handling of the shakapacker script and development server. The modifications include setting environment variables more appropriately and ensuring packs are generated before compilation to streamline the development workflow.

Changes

Files/Paths Change Summary
Gemfile.development_dependencies Added gem "debug" to the development and test group.
spec/dummy/Procfile.dev Changed SERVER_BUNDLE_ONLY from yes to true in the wp-server command.
spec/dummy/bin/shakapacker Added a block to conditionally load a Rakefile and invoke a task based on SERVER_BUNDLE_ONLY.
spec/dummy/bin/shakapacker-dev-server Added a recommendation to generate packs before running DevServerRunner.

Poem

🐇

In the world of code, we dance and debug,
With gems and scripts, we give a snug hug.
Packs are prepped before the server's hum,
Ensuring our workflows smoothly run.
A tweak here, a gem there, we refine,
Making development simply divine.

🛠️✨


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share
Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a 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

Commits

Files that changed from the base of the PR and between 75c6602 and 4f48512.

Files ignored due to path filters (2)
  • spec/dummy/Gemfile.lock is excluded by !**/*.lock
  • spec/dummy/yarn.lock is excluded by !**/*.lock
Files selected for processing (4)
  • Gemfile.development_dependencies (1 hunks)
  • spec/dummy/Procfile.dev (1 hunks)
  • spec/dummy/bin/shakapacker (1 hunks)
  • spec/dummy/bin/shakapacker-dev-server (1 hunks)
Files skipped from review due to trivial changes (3)
  • Gemfile.development_dependencies
  • spec/dummy/Procfile.dev
  • spec/dummy/bin/shakapacker-dev-server
Additional comments not posted (1)
spec/dummy/bin/shakapacker (1)

12-13: Ensure that the rake gem is included in the Gemfile to avoid runtime errors.

Comment on lines +14 to +20
# Recommendation is to generate packs before compilation.
# SERVER_BUNDLE_ONLY is true when also running the bin/shakapacker-dev-server,
# so no need to run twice.
unless ENV["SERVER_BUNDLE_ONLY"] == "true"
Rake.application.load_rakefile
Rake::Task["react_on_rails:generate_packs"].invoke
end
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The conditional execution logic is clear and well-commented.

However, consider adding error handling for the Rake task invocation to manage potential failures gracefully.

-  Rake::Task["react_on_rails:generate_packs"].invoke
+  begin
+    Rake::Task["react_on_rails:generate_packs"].invoke
+  rescue Exception => e
+    puts "Failed to generate packs: #{e.message}"
+    exit 1
+  end
Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
# Recommendation is to generate packs before compilation.
# SERVER_BUNDLE_ONLY is true when also running the bin/shakapacker-dev-server,
# so no need to run twice.
unless ENV["SERVER_BUNDLE_ONLY"] == "true"
Rake.application.load_rakefile
Rake::Task["react_on_rails:generate_packs"].invoke
end
# Recommendation is to generate packs before compilation.
# SERVER_BUNDLE_ONLY is true when also running the bin/shakapacker-dev-server,
# so no need to run twice.
unless ENV["SERVER_BUNDLE_ONLY"] == "true"
Rake.application.load_rakefile
begin
Rake::Task["react_on_rails:generate_packs"].invoke
rescue Exception => e
puts "Failed to generate packs: #{e.message}"
exit 1
end
end

@justin808 justin808 merged commit 7b3aab7 into master Jun 12, 2024
@justin808 justin808 deleted the justin808/misc-fixes branch June 12, 2024 03:32
ihabadham added a commit that referenced this pull request Apr 2, 2026
…e convention

The spec/dummy used `SERVER_BUNDLE_ONLY=true` while the generator template
and all other Procfiles use `=yes`. The inconsistency was introduced
accidentally in PR #1630 and has no functional impact (webpack checks
truthiness, not exact string), but aligning with the template convention
keeps the spec/dummy representative of what users get.

Closes #2409

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
ihabadham added a commit that referenced this pull request Apr 2, 2026
…ention (#2922)

## Summary
- Aligns `spec/dummy/Procfile.dev` to use `SERVER_BUNDLE_ONLY=yes`
instead of `=true`, matching the generator template and all other
Procfiles in the codebase
- Also fixes `CLIENT_BUNDLE_ONLY=true` → `=yes` in the RSC "how it
works" doc, which had the same inconsistency
- Both inconsistencies are purely cosmetic — webpack configs check
truthiness (`if (process.env.X)`), not exact string equality

## Context
- The `SERVER_BUNDLE_ONLY` inconsistency was introduced accidentally in
PR #1630 (June 2024) when the value was changed from `=yes` to `=true`
without review
- The `CLIENT_BUNDLE_ONLY` inconsistency in
`docs/pro/react-server-components/how-react-server-components-work.md`
was found during investigation — all other `CLIENT_BUNDLE_ONLY` usage
(`server_manager.rb`, specs, other docs) uses `=yes`

Closes #2409

## Test plan
- [x] CI passes (no functional change — both `"yes"` and `"true"` are
truthy in JS)
- [x] Verify `spec/dummy/Procfile.dev` now matches the template
convention
- [x] Verify RSC doc commands match the codebase convention

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Chores**
* Updated development/build configuration to adjust a server bundle
setting for consistent local tooling behavior.
* Updated documentation to reflect the revised build command and clarify
the local development workflow.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>
justin808 pushed a commit that referenced this pull request Apr 12, 2026
…ention (#2922)

## Summary
- Aligns `spec/dummy/Procfile.dev` to use `SERVER_BUNDLE_ONLY=yes`
instead of `=true`, matching the generator template and all other
Procfiles in the codebase
- Also fixes `CLIENT_BUNDLE_ONLY=true` → `=yes` in the RSC "how it
works" doc, which had the same inconsistency
- Both inconsistencies are purely cosmetic — webpack configs check
truthiness (`if (process.env.X)`), not exact string equality

## Context
- The `SERVER_BUNDLE_ONLY` inconsistency was introduced accidentally in
PR #1630 (June 2024) when the value was changed from `=yes` to `=true`
without review
- The `CLIENT_BUNDLE_ONLY` inconsistency in
`docs/pro/react-server-components/how-react-server-components-work.md`
was found during investigation — all other `CLIENT_BUNDLE_ONLY` usage
(`server_manager.rb`, specs, other docs) uses `=yes`

Closes #2409

## Test plan
- [x] CI passes (no functional change — both `"yes"` and `"true"` are
truthy in JS)
- [x] Verify `spec/dummy/Procfile.dev` now matches the template
convention
- [x] Verify RSC doc commands match the codebase convention

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Chores**
* Updated development/build configuration to adjust a server bundle
setting for consistent local tooling behavior.
* Updated documentation to reflect the revised build command and clarify
the local development workflow.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>
justin808 pushed a commit that referenced this pull request Apr 12, 2026
…ention (#2922)

## Summary
- Aligns `spec/dummy/Procfile.dev` to use `SERVER_BUNDLE_ONLY=yes`
instead of `=true`, matching the generator template and all other
Procfiles in the codebase
- Also fixes `CLIENT_BUNDLE_ONLY=true` → `=yes` in the RSC "how it
works" doc, which had the same inconsistency
- Both inconsistencies are purely cosmetic — webpack configs check
truthiness (`if (process.env.X)`), not exact string equality

## Context
- The `SERVER_BUNDLE_ONLY` inconsistency was introduced accidentally in
PR #1630 (June 2024) when the value was changed from `=yes` to `=true`
without review
- The `CLIENT_BUNDLE_ONLY` inconsistency in
`docs/pro/react-server-components/how-react-server-components-work.md`
was found during investigation — all other `CLIENT_BUNDLE_ONLY` usage
(`server_manager.rb`, specs, other docs) uses `=yes`

Closes #2409

## Test plan
- [x] CI passes (no functional change — both `"yes"` and `"true"` are
truthy in JS)
- [x] Verify `spec/dummy/Procfile.dev` now matches the template
convention
- [x] Verify RSC doc commands match the codebase convention

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Chores**
* Updated development/build configuration to adjust a server bundle
setting for consistent local tooling behavior.
* Updated documentation to reflect the revised build command and clarify
the local development workflow.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant