Walkthrough

Sets SWC as the default JavaScript transpiler across config and installer, removes Babel from peer dependencies, and adds validation for Babel packages when explicitly selected. Updates installer logic, package templates, tests, and docs (including upgrade and performance guidance). Introduces CSS Modules named exports guidance in docs.

Changes

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant Dev as Developer
  participant Rails as Rails Installer (template.rb)
  participant Pkg as Package Manager
  participant FS as Project Files

  Dev->>Rails: run install generator
  Rails->>Rails: read shakapacker.yml (default transpiler = swc)
  alt transpiler = babel
    Rails->>Pkg: install babel deps (+ optional SWC deps where required)
  else transpiler = swc
    Rails->>Pkg: install @swc/core, swc-loader
  else transpiler = esbuild
    Rails->>Pkg: install esbuild, esbuild-loader
  end
  Rails->>FS: write config/shakapacker.yml
  Rails->>FS: scaffold configs, binstubs, packs
  Pkg-->>Rails: install results (ok/error)
  Rails-->>Dev: complete or abort with error

sequenceDiagram
  autonumber
  participant Build as Build Config Loader
  participant Helpers as utils/helpers.js
  participant Env as Node Modules

  Build->>Helpers: determine loader (babel/swc/esbuild)
  alt loader = babel
    Helpers->>Env: check @babel/core, babel-loader
    alt missing core deps
      Helpers-->>Build: throw with fix command + SWC tip
    else present
      Helpers-->>Build: proceed with babel loader
    end
  else loader = swc
    Helpers-->>Build: proceed with swc loader (install guidance if missing)
  else loader = esbuild
    Helpers-->>Build: proceed with esbuild loader (install guidance if missing)
  end

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

• Add logic to sass rule conditional on sass-loader version #508 — Both modify package/utils/helpers.js to add new exported helpers, indicating related helper expansion and export surface changes.
• Implement dual webpack/rspack architecture with conditional dependencies #590 — Both touch bundler/transpiler config wiring for webpack/rspack; this PR further changes the default to SWC.
• feat: CSS Modules use named exports by default in v9 #599 — Both involve CSS Modules export behavior updates impacting loader configuration and docs.

Suggested reviewers

• tomdracz

Poem

I thump my paws, a swift new run,
SWC now greets the rising sun.
Babel bows—still welcome, friend—
Choose your path, the builds ascend.
With camelCased threads we weave,
I hop, I ship, then take my leave. 🐇✨

Pre-merge checks and finishing touches

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 @coderabbitai help to get the list of available commands and usage tips.}

Code Review for PR #603: Make babel dependencies optional

Thank you for this well-considered PR that makes babel truly optional in Shakapacker v9! This is a significant improvement that aligns with modern JavaScript tooling practices. Here's my comprehensive review:

✅ Strengths

1. Excellent backward compatibility: The implementation thoughtfully maintains compatibility by defaulting to babel for v9, ensuring existing projects continue to work without modification.

2. Smart conditional installation logic: The fetch_babel_dependencies method intelligently checks the configuration and only installs babel when needed.

3. Comprehensive documentation: The changes include thorough documentation updates in CHANGELOG.md, v9_upgrade.md, and peer-dependencies.md, making the migration path clear.

4. Research-driven approach: The included babel-removal-investigation.md shows careful analysis of the feasibility and impact of this change.

🎯 Code Quality Observations

1. Configuration detection logic (lib/install/template.rb:124-127): The fallback chain for detecting the transpiler configuration is good, but consider extracting this into a helper method for reusability:

   def configured_javascript_transpiler
     shakapacker_config = YAML.load_file(Rails.root.join("config/shakapacker.yml"))
     shakapacker_config.dig("default", "javascript_transpiler") || 
     shakapacker_config.dig("production", "javascript_transpiler") || 
     "babel"
   end

2. YAML.load_file usage: Consider using YAML.safe_load instead of YAML.load_file for better security, though the risk is minimal since it's reading a config file:

   shakapacker_config = YAML.safe_load(File.read(Rails.root.join("config/shakapacker.yml")))

⚠️ Potential Issues

1. Missing error handling: The template.rb code doesn't handle the case where config/shakapacker.yml might not exist yet during initial installation. Consider adding a rescue block:

   begin
     shakapacker_config = YAML.load_file(Rails.root.join("config/shakapacker.yml"))
   rescue Errno::ENOENT
     shakapacker_config = {}
   end

2. Environment-specific configuration: The current logic only checks "default" and "production" environments. Consider also checking the current Rails environment:

   javascript_transpiler = shakapacker_config.dig(Rails.env, "javascript_transpiler") ||
                          shakapacker_config.dig("default", "javascript_transpiler") || 
                          shakapacker_config.dig("production", "javascript_transpiler") || 
                          "babel"

📊 Performance Considerations

• Excellent impact: Removing ~100MB of unused babel dependencies for swc/esbuild users is a significant win.
• The performance note about swc being "20x faster" is well-placed in the documentation.

🔒 Security

• No security concerns identified. The conditional installation approach is safe and doesn't introduce any new attack vectors.

✅ Test Coverage

• The PR indicates JavaScript tests pass and mentions manual testing needs for different transpilers.
• Consider adding automated tests for the fetch_babel_dependencies method to ensure it correctly detects different configuration scenarios.

📝 Minor Suggestions

1. CHANGELOG.md PR link: Update the placeholder [PR xxx] with the actual PR number Make babel dependencies optional instead of peer dependencies #603.

2. Investigation file placement: Consider moving babel-removal-investigation.md to a docs/decisions/ or docs/adr/ directory to keep the root clean and establish a pattern for architectural decision records.

3. Config comment clarity: The comment in shakapacker.yml could be even clearer:

   # Note: babel dependencies are only installed when this is set to 'babel'
   # For better performance, consider using 'swc' (20x faster) or 'esbuild'
   javascript_transpiler: 'babel'

🚀 Overall Assessment

This is a high-quality PR that makes a meaningful improvement to Shakapacker. The change is well-thought-out, maintains backward compatibility, and provides clear benefits to users. With the minor improvements suggested above (particularly the error handling for missing config files), this PR is ready for merge.

The breaking change is handled responsibly with clear documentation and migration guidance. Great work on reducing dependencies and pushing the ecosystem toward faster, modern transpilers!

Recommendation: Approve with minor suggestions ✅

🤖 Generated with Claude Code

Co-Authored-By: Claude [email protected]

Code Review for PR #603: Make babel dependencies optional

Thank you for this important improvement to Shakapacker v9! This change aligns well with the modern JavaScript ecosystem's move away from Babel toward faster alternatives. Here's my comprehensive review:

✅ Strengths

1. Excellent Backward Compatibility: The implementation ensures existing projects continue to work unchanged while enabling new projects to benefit from reduced dependencies.

2. Smart Conditional Installation: The template.rb logic properly detects the transpiler configuration and installs babel only when needed. The fallback to babel for backward compatibility (line 127) is well thought out.

3. Comprehensive Documentation: The changes to v9_upgrade.md, peer-dependencies.md, and CHANGELOG.md provide clear migration guidance and context for users.

4. Performance Focus: The config comments recommending SWC (20x faster) encourage users toward better-performing alternatives.

🔍 Potential Issues & Suggestions

1. YAML Parsing Without Error Handling (lib/install/template.rb:125)

   shakapacker_config = YAML.load_file(Rails.root.join("config/shakapacker.yml"))

   Consider adding error handling for missing or malformed config files:

   begin
     shakapacker_config = YAML.load_file(Rails.root.join("config/shakapacker.yml"))
   rescue Errno::ENOENT, Psych::SyntaxError => e
     say "Warning: Unable to read shakapacker config: #{e.message}. Defaulting to babel.", :yellow
     shakapacker_config = {}
   end

2. Configuration Priority Logic (lib/install/template.rb:126-128)
   The current logic checks default then production, but Rails environment-specific settings should take precedence. Consider:

   javascript_transpiler = shakapacker_config.dig(Rails.env, "javascript_transpiler") ||
                           shakapacker_config.dig("default", "javascript_transpiler") ||
                           "babel"

3. PR Link Placeholder (CHANGELOG.md:19)
   The changelog contains [PR xxx] - this should be updated to [PR 603].

📊 Performance Considerations

✅ Positive Impact:

• Reduces node_modules size by ~100MB for non-babel users
• Faster npm/yarn install times for projects using swc/esbuild
• No runtime performance impact

🔒 Security Review

✅ No security concerns identified. The change reduces the attack surface by removing unnecessary dependencies.

🧪 Test Coverage

The PR mentions JavaScript tests pass, but consider adding:

• Integration tests for fresh Rails app installation with different transpilers
• Unit tests for the conditional babel installation logic
• Edge case testing (missing config, invalid transpiler values)

💡 Additional Recommendations

1. Migration Script: Consider providing a script to help existing users remove babel dependencies when switching to swc/esbuild.

2. Telemetry/Analytics: If you collect usage stats, tracking transpiler adoption would help inform future defaults.

3. Future Enhancement: The babel-removal-investigation.md file provides excellent analysis but should probably not be committed to the main branch. Consider moving this to a GitHub discussion or wiki.

✅ Conclusion

This is a well-implemented breaking change that improves Shakapacker significantly while maintaining excellent backward compatibility. The code quality is good, and the approach is sound. With the minor improvements suggested above (especially the error handling), this PR is ready to merge.

Great work on modernizing Shakapacker's dependency management! 🎉

🤖 Generated with Claude Code

Co-Authored-By: Claude [email protected]

Code Review for PR #603: Make babel dependencies optional

Thank you for this well-structured PR that makes Babel dependencies optional! This is a meaningful improvement that aligns well with Shakapacker v9's multi-transpiler support strategy. Here's my comprehensive review:

✅ Strengths

1. Clear value proposition: Reducing node_modules by ~100MB for non-Babel users is significant
2. Backward compatibility: Existing projects remain unaffected as babel packages stay in their package.json
3. Documentation: Excellent updates across CHANGELOG, upgrade guide, and peer-dependencies docs
4. Migration path: Clear guidance for users switching transpilers

🔍 Issues & Suggestions

1. Critical Bug in template.rb ⚠️

The new conditional logic in lib/install/template.rb (lines 125-143) attempts to read YAML config during installation, but this will fail for new Rails apps where config/shakapacker.yml doesn't exist yet. The template copies the config file (line 10) but then immediately tries to read it (line 126).

Fix needed: Check if config file exists before reading it, and default to babel for new installations to maintain backward compatibility.

2. CHANGELOG PR Link Missing

Line in CHANGELOG.md references [PR xxx] - should be updated to actual PR number #603.

3. Investigation File Committed

The babel-removal-investigation.md file appears to be internal investigation notes. Consider removing it from the PR unless it's intended as permanent documentation.

💡 Performance Considerations

✅ Excellent: The 20x performance improvement with SWC is well-documented
✅ Installation time: Reduced dependency installation time for non-Babel users

🔐 Security

✅ No security concerns identified. The changes properly handle configuration without exposing sensitive data.

🧪 Test Coverage

✅ The test plan in PR description shows appropriate coverage
⚠️ Consider adding a specific test for the new conditional babel installation logic to prevent regression

📝 Minor Suggestions

1. In docs/peer-dependencies.md, consider adding version constraints for SWC/esbuild similar to Babel's explicit versions
2. The config comment could mention approximate build time improvements (e.g., typically 10-20x faster)

Conclusion

This is a valuable improvement that makes Shakapacker more flexible and performant. The critical issue with template.rb must be fixed before merging to ensure new Rails app installations work correctly. Once that's addressed, this PR will be ready to merge.

Great work on making Shakapacker lighter and more modular! 🎉

🤖 Generated with Claude Code

Co-Authored-By: Claude [email protected]

Pull Request Review - Make Babel Dependencies Optional

Thank you for this well-structured PR that makes Babel dependencies truly optional in Shakapacker v9! This is a significant improvement that aligns with modern JavaScript tooling practices.

Strengths

1. Architecture & Implementation - Clean separation of concerns in template.rb with well-organized conditional loading logic
2. Smart defaults - Making SWC the default transpiler is excellent given its 20x performance improvement
3. Backward compatibility - Existing Babel projects continue working without changes
4. Documentation - Comprehensive migration guide and clear breaking change notifications
5. Test coverage - Proper mocking and validation of conditional behavior

Suggestions for Improvement

1. Error Handling - Consider adding validation when babel is configured but dependencies are missing
2. Configuration Consistency - The code checks multiple config locations - consider centralizing this logic
3. Version Management - Using "latest" for SWC/esbuild could cause breaking changes - pin major versions
4. Performance Docs - Add benchmarks comparing transpiler performance for different project sizes

Potential Issues

1. Multiple Config Reads - shakapacker.yml is read 4 times, consider reading once and passing to helpers
2. Edge Case - What if USE_BABEL_PACKAGES=1 with javascript_transpiler: swc? Both would install

Security & Performance

• No security concerns identified
• Significant improvements: ~100MB smaller node_modules, faster install times, 20x build speed with SWC

Overall Assessment

High-quality PR that successfully makes Babel optional while maintaining backward compatibility. Implementation is clean, well-documented, and properly tested. Ready for merge after addressing version pinning.

Recommendation: Approve with minor suggestions

Great work on modernizing Shakapacker!

Generated with Claude Code
Co-Authored-By: Claude [email protected]

🎯 Code Review for PR #603: Make babel dependencies optional

Overall Assessment

This PR successfully transitions Shakapacker from required Babel dependencies to an optional, transpiler-agnostic approach with SWC as the new default. The implementation is well-thought-out with excellent backward compatibility.

✅ Strengths

1. Backward Compatibility: Excellent auto-detection logic ensures existing Babel projects continue working without changes
2. Performance Focus: SWC as default provides 20x performance improvement for new projects
3. Clear Migration Path: Well-documented upgrade paths in both directions (Babel ↔ SWC)
4. User-Friendly Error Messages: Enhanced error handling with installation commands and migration tips
5. Comprehensive Documentation: New transpiler-performance.md file provides valuable benchmarks

🔍 Areas for Improvement

1. Installer Template Complexity

The lib/install/template.rb file has become quite complex with inline logic. Consider:

• Extracting transpiler detection/installation logic into a separate module
• The dual installation of both Babel and SWC when USE_BABEL_PACKAGES=true might be confusing

2. Version Pinning

swc_deps = { "@swc/core" => "^1.3.0", "swc-loader" => "^0.2.0" }

Consider using more flexible version ranges or pulling from a centralized config like the existing lib/install/package.json

3. Error Handling Enhancement

In package/utils/helpers.js, the error messages are helpful but could benefit from:

// Consider adding a link to the migration guide
migrationHelp = 
  "\n\n💡 Tip: Consider migrating to SWC for 20x faster compilation:\n" +
  "   See: https://github.com/shakacode/shakapacker/blob/main/docs/transpiler-performance.md"

4. Test Coverage

The test modification in babel.test.js correctly sets the transpiler, but consider adding:

• Tests for the auto-detection logic
• Tests for error scenarios when transpiler packages are missing
• Integration tests for each transpiler option

🐛 Potential Issues

1. Package.json Babel Config: When switching from Babel to SWC, the babel config remains in package.json. Consider adding cleanup logic or documentation about removing it.

2. Rspack Compatibility: The comment mentions rspack includes SWC natively, but the installer still installs SWC packages. Verify this doesn't cause conflicts.

🔒 Security Considerations

• No security vulnerabilities identified
• Package versions use appropriate constraints
• No hardcoded credentials or sensitive data

💡 Suggestions

1. Add a migration command: Consider adding a rake task like rails shakapacker:migrate_transpiler[swc] to automate the migration process

2. Performance monitoring: Add telemetry or logging to track which transpiler users are adopting to inform future decisions

3. Deprecation timeline: Consider adding a deprecation timeline for Babel support to guide users toward better performance

✨ Minor Code Quality Items

1. Add trailing newline to docs/transpiler-performance.md per CLAUDE.md requirements
2. Consider consistent messaging format (some use emojis, some don't)

📊 Performance Impact

The documented 20x performance improvement with SWC is significant and will greatly benefit the Rails ecosystem. The benchmarks provided are thorough and convincing.

✅ Recommendation

APPROVED with minor suggestions. This is a well-executed change that provides significant performance benefits while maintaining excellent backward compatibility. The migration path is clear and the documentation is comprehensive.

Great work on balancing innovation with stability! 🎉

🤖 Generated with Claude Code

Co-Authored-By: Claude [email protected]

Code Review for PR #603: Make babel dependencies optional

Overall Assessment

This is a well-thought-out change that significantly improves the Shakapacker installation experience and performance. The switch to SWC as the default transpiler while maintaining backward compatibility is expertly handled.

✅ Strengths

1. Excellent Backward Compatibility: The auto-detection of existing Babel configurations ensures zero breaking changes for existing projects.

2. Clear Migration Path: The documentation and error messages provide excellent guidance for users migrating between transpilers.

3. Performance Benefits: The 20x performance improvement with SWC is well-documented with comprehensive benchmarks.

4. Smart Dependency Management: The conditional installation of transpiler dependencies reduces node_modules size significantly.

🔍 Code Quality Observations

1. Installation Logic (template.rb):

   • The dual-installation strategy when USE_BABEL_PACKAGES=true (installing both Babel and SWC) is clever for maintaining compatibility
   • Good use of instance variables to avoid Rails template method definition issues
   • Proper error handling with helpful messages

2. Error Messages (helpers.js):

   • The enhanced error messages with installation commands and migration tips are very user-friendly
   • The validateBabelDependencies() function properly checks only core dependencies while suggesting optional ones

3. Version Handling:

   • Good improvement in handling version strings like ^1.3.0 directly instead of extracting major versions

⚠️ Potential Issues

1. Version String Parsing (template.rb:184-192):

   if version.start_with?("^") || version.start_with?("~") || version.match?(/^\d+\.\d+/)

   This regex could miss some valid semver formats. Consider using a more comprehensive pattern or a semver parsing library.

2. Babel Preset Configuration:
   The babel preset is only added when @transpiler_to_install == "babel", but what happens if a user manually switches to babel later? Consider documenting this manual step.

🎯 Performance Considerations

• The benchmarks are impressive and well-documented
• The default switch to SWC will significantly improve CI/CD times
• Consider adding a note about memory usage differences in development mode

🔒 Security Review

• No security concerns identified
• Dependencies are installed with appropriate version constraints
• No credentials or sensitive information exposed

✅ Test Coverage

• The test file properly mocks the config to force babel usage
• Consider adding integration tests for the installation process with different transpilers
• May want to add tests for the version string parsing logic

📝 Suggestions for Improvement

1. Documentation Enhancement: Consider adding a troubleshooting section for common migration issues

2. Installation Feedback: The installation process could show estimated time savings when using SWC

3. Config Validation: Consider adding a rake task to validate the transpiler configuration and dependencies

Conclusion

This is a high-quality PR that successfully modernizes Shakapacker's build pipeline while maintaining excellent backward compatibility. The code is clean, well-documented, and the migration path is clear. The performance improvements alone make this a valuable addition.

Approved ✅ - Ready to merge after considering the minor suggestions above.

🤖 Generated with Claude Code

Code Review for PR #603: Make babel dependencies optional

🎯 Summary

This PR successfully implements a major improvement by making Babel dependencies optional and defaulting to SWC for new installations. The change is well-executed with thoughtful backward compatibility considerations.

✅ Strengths

1. Excellent Backward Compatibility

• Smart auto-detection of existing Babel configurations preserves current setups
• Dual installation strategy when USE_BABEL_PACKAGES=true ensures smooth testing
• Clear migration paths in both directions (Babel ↔ SWC)

2. Performance Benefits

• 20x compilation speed improvement with SWC as default
• Significant reduction in node_modules size (~100MB savings)
• Comprehensive performance benchmarks documentation

3. Code Quality

• Clean separation of concerns in the installer logic
• Helpful error messages with actionable installation commands
• Well-structured conditional dependency installation

4. Documentation

• Thorough migration guides and upgrade instructions
• New transpiler performance benchmarks document
• Clear changelog entries with migration options

⚠️ Potential Issues

1. Version Handling Edge Case (lib/install/template.rb:183-192)
The regex /^\d+.\d+/ might match partial versions incorrectly. Consider using a more specific pattern like /^\d+.\d+.\d+$/.

2. Mock Implementation in Tests (test/package/rules/babel.test.js:37-44)
The mock for validateBabelDependencies is placed in beforeAll but the actual mocking happens inside, which may not work as expected. Consider moving the jest.mock call outside the describe block.

💡 Suggestions for Improvement

1. Enhanced Error Recovery
Consider adding a fallback mechanism if SWC installation fails, perhaps automatically suggesting Babel as an alternative.

2. Migration Tool
A future enhancement could include a rake task to automatically migrate projects from Babel to SWC, handling configuration updates and dependency management.

3. Test Coverage
While test coverage looks good, consider adding:

• Integration tests for the auto-detection logic
• Tests for the version string handling edge cases
• End-to-end tests for both new and upgrade scenarios

🔒 Security Considerations

• No security concerns identified
• Proper version pinning maintained
• No credentials or sensitive data exposed

✅ Test Plan Verification

• ✅ JavaScript tests covered
• ✅ Installation detection tests present
• ✅ Documentation thoroughly updated
• ⚠️ Manual testing with fresh Rails apps and existing Babel projects still pending (as noted in PR description)

📊 Performance Impact

The benchmarks clearly demonstrate significant performance improvements:

• Small projects: 20x faster
• Medium projects: 25x faster
• Large projects: 22x faster
• Memory usage: 50-70% reduction

🏁 Conclusion

Approved with minor suggestions 👍

This is a well-thought-out change that provides immediate value to users while maintaining excellent backward compatibility. The default switch to SWC will significantly improve the developer experience for new projects, and the migration paths are clear for existing projects.

The minor issues identified don't block merging but should be considered for follow-up improvements. Great work on balancing innovation with stability!

🤖 Generated with Claude Code

Pull Request Review: Make babel dependencies optional instead of peer dependencies

Overall Assessment

This is a well-executed PR that successfully makes Babel dependencies optional while defaulting to the faster SWC transpiler. The implementation maintains backward compatibility while providing significant performance benefits (20x faster compilation).

Strengths

1. Excellent backward compatibility: The auto-detection of existing Babel configurations ensures existing projects continue working without changes.

2. Clear migration path: Both upgrade and downgrade paths are well-documented with specific commands.

3. Comprehensive documentation: The new transpiler-performance.md provides valuable benchmarks and clear recommendations.

4. Smart dependency management: The conditional installation logic properly handles different transpiler choices.

5. Helpful error messages: Clear, actionable error messages guide users through dependency installation.

Areas for Attention

1. Edge Case in Version Handling

In lib/install/template.rb:184-191, the version parsing logic could fail for certain version formats. The regex could raise an error if no digits are found in the version string.

Suggestion: Add a fallback or validation to handle edge cases where version strings might not contain digits.

2. Double Installation When USE_BABEL_PACKAGES=true

When USE_BABEL_PACKAGES is set, the code installs both Babel AND SWC packages. While this ensures compatibility, it might confuse users about which transpiler is actually being used.

Suggestion: Add a clear message explaining why both are being installed.

3. Test Coverage Enhancement

The test mocks validateBabelDependencies to avoid actual dependency checking. Consider adding integration tests that verify the actual dependency installation logic.

Performance Considerations

The documented 20x performance improvement with SWC is impressive. The benchmarks in transpiler-performance.md effectively demonstrate the benefits across different project sizes.

Security

No security concerns identified. The PR does not introduce any new attack vectors or expose sensitive information.

Test Coverage

Tests appropriately mock the new validation function. The existing test suite appears adequate for the changes made.

Minor Suggestions

1. Consider adding a migration script: A rake task like shakapacker:migrate_to_swc could automate the migration process for existing projects.

2. Runtime validation: Consider adding a runtime check that warns if babel packages are installed but SWC is configured (or vice versa) to help catch configuration mismatches.

3. Package.json cleanup: Consider providing guidance or a utility to help users remove unused babel dependencies from their package.json after migrating to SWC.

Conclusion

This is a high-quality PR that successfully achieves its goals while maintaining excellent backward compatibility. The performance improvements alone make this a valuable addition. The code is well-structured, the documentation is comprehensive, and the migration path is clear.

Recommendation: Approve with minor suggestions

The edge case in version handling should be addressed before merging to prevent potential runtime errors. The other suggestions are nice-to-haves that could be addressed in follow-up PRs.

Great work on making Shakapacker faster and more efficient while keeping the upgrade path smooth!

Generated with Claude Code (https://claude.ai/code)