Improve CSS Modules backward compatibility documentation (#809)#810
Improve CSS Modules backward compatibility documentation (#809)#810
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 3 minutes and 52 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 (1)
WalkthroughUpdates Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes
Possibly related issues
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (5 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 |
Introduce a simple configuration option to control CSS Modules export mode, making it much easier for users to restore v8 behavior without manually overriding webpack configuration. Changes: - Add `css_modules_export_mode` option to shakapacker.yml - 'named' (default): Use named exports with camelCaseOnly (v9 behavior) - 'default': Use default exports with camelCase (v8 behavior) - Implement logic in getStyleRule.ts to apply configuration - Add TypeScript type definition for new config option - Update CSS Modules documentation with new configuration approach - Update v9 upgrade guide to highlight the simple config option Benefits: - Users can set one line in shakapacker.yml instead of writing custom webpack config - Reduces migration friction for large codebases - Provides clear, documented path for gradual migration - Maintains backward compatibility while encouraging modern practices Example usage: ```yaml # config/shakapacker.yml css_modules_export_mode: "default" # Restore v8 behavior ``` This complements the documentation improvements in PR #810 by providing a user-friendly configuration option that doesn't require webpack expertise. Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Introduce a simple configuration option to control CSS Modules export mode, making it much easier for users to restore v8 behavior without manually overriding webpack configuration. Changes: - Add `css_modules_export_mode` option to shakapacker.yml - 'named' (default): Use named exports with camelCaseOnly (v9 behavior) - 'default': Use default exports with camelCase (v8 behavior) - Implement logic in getStyleRule.ts to apply configuration - Add TypeScript type definition for new config option - Update CSS Modules documentation with new configuration approach - Update v9 upgrade guide to highlight the simple config option Benefits: - Users can set one line in shakapacker.yml instead of writing custom webpack config - Reduces migration friction for large codebases - Provides clear, documented path for gradual migration - Maintains backward compatibility while encouraging modern practices Example usage: ```yaml # config/shakapacker.yml css_modules_export_mode: "default" # Restore v8 behavior ``` This complements the documentation improvements in PR #810 by providing a user-friendly configuration option that doesn't require webpack expertise. Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Introduce a simple configuration option to control CSS Modules export mode, making it much easier for users to restore v8 behavior without manually overriding webpack configuration. Changes: - Add `css_modules_export_mode` option to shakapacker.yml - 'named' (default): Use named exports with camelCaseOnly (v9 behavior) - 'default': Use default exports with camelCase (v8 behavior) - Implement logic in getStyleRule.ts to apply configuration - Add TypeScript type definition for new config option - Update CSS Modules documentation with new configuration approach - Update v9 upgrade guide to highlight the simple config option Benefits: - Users can set one line in shakapacker.yml instead of writing custom webpack config - Reduces migration friction for large codebases - Provides clear, documented path for gradual migration - Maintains backward compatibility while encouraging modern practices Example usage: ```yaml # config/shakapacker.yml css_modules_export_mode: "default" # Restore v8 behavior ``` This complements the documentation improvements in PR #810 by providing a user-friendly configuration option that doesn't require webpack expertise. Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
## Summary Introduces a simple, user-friendly configuration option to control CSS Modules export mode, making it much easier to restore v8 behavior without manual webpack configuration overrides. ## Problem Solved Issue #809 identified that upgrading from Shakapacker v8 to v9 requires complex webpack configuration overrides to maintain v8 CSS Modules behavior. This creates a high barrier for teams with large codebases who need to migrate gradually. ## Solution Add a `css_modules_export_mode` configuration option to `shakapacker.yml`: ```yaml # config/shakapacker.yml default: &default # CSS Modules export mode # 'named' (default) - Use named exports with camelCase conversion (v9 default) # 'default' - Use default export with both original and camelCase names (v8 behavior) css_modules_export_mode: "named" ``` ## Changes 1. **Configuration Schema** (`lib/install/config/shakapacker.yml`) - Added `css_modules_export_mode` option with clear documentation - Defaults to `"named"` to maintain v9 behavior 2. **TypeScript Types** (`package/types.ts`) - Added `css_modules_export_mode?: "named" | "default"` to Config interface - Provides type safety and IDE autocomplete 3. **Implementation** (`package/utils/getStyleRule.ts`) - Reads configuration and applies appropriate CSS loader settings - `"named"`: Sets `namedExport: true` and `exportLocalsConvention: "camelCaseOnly"` (v9 default) - `"default"`: Sets `namedExport: false` and `exportLocalsConvention: "camelCase"` (v8 behavior) 4. **Documentation Updates** - Updated `docs/css-modules-export-mode.md` with new configuration approach - Updated `docs/v9_upgrade.md` to highlight the simple config option first - Reorganized migration options to emphasize the easiest approach ## Benefits - **No webpack expertise required** - Users just change one line in YAML - **Reduced migration friction** - Large codebases can upgrade immediately - **Clear migration path** - Simple to enable v8 mode, then gradually migrate - **Maintains best practices** - Defaults to v9 behavior, but provides escape hatch - **Better than PR #810** - While that PR improved documentation, this provides a programmatic solution ## Example Usage ### Keeping v8 Behavior ```yaml # config/shakapacker.yml css_modules_export_mode: "default" ``` Then continue using v8-style imports: ```javascript import styles from './Component.module.css'; <button className={styles.button} /> ``` ### Using v9 Behavior (Default) ```yaml # config/shakapacker.yml css_modules_export_mode: "named" # or omit this line ``` Use v9-style imports: ```javascript // JavaScript import { button } from './Component.module.css'; <button className={button} /> // TypeScript import * as styles from './Component.module.css'; <button className={styles.button} /> ``` ## Migration Strategy 1. **Immediate upgrade**: Set `css_modules_export_mode: "default"` to maintain v8 behavior 2. **Gradual migration**: Update components incrementally to use named exports 3. **Complete migration**: Remove the config option to use v9 default ## Test Plan - [x] Linting passes (`yarn lint`) - [x] RuboCop passes (`bundle exec rubocop`) - [x] TypeScript type checking passes (`yarn run tsc --noEmit`) - [x] Configuration is properly typed - [x] Documentation is clear and comprehensive ## Related - Addresses issue #809 - Complements PR #810 (documentation improvements) - Supersedes manual webpack configuration approach Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a configurable CSS Modules export mode allowing projects to use either v8-style default imports or v9-style named exports. * **Documentation** * Expanded upgrade and CSS Modules guides with step-by-step configuration examples and migration options (easy config-driven or advanced manual approaches). * **Tests** * Updated test coverage to validate mode-dependent CSS Modules behavior. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <[email protected]>
Add complete working example to v9 upgrade guide showing how to restore v8 CSS Modules behavior using webpack configuration. This addresses the documentation gap where users needed to figure out the exact configuration on their own. The example includes: - Complete working webpack config code - Detailed explanation of each step - Key points about file extensions and validation - Clear note that this is a temporary solution Fixes #809 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
justin808
force-pushed
the
justin808/css-modules-compat-docs
branch
from
a0edfc7 to
2a7ee5e
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
docs/v9_upgrade.md (1)
157-206: Excellent documentation of webpack override with defensive programming approach.The webpack configuration override example is well-structured with appropriate safety checks (property existence, Array validation, loader identification). The code handles the common rule structure effectively and documents key points clearly.
One minor suggestion: Consider adding a brief note about testing the override (e.g.,
bin/shakapackeroryarn buildto verify the config applies correctly and doesn't break the build). This would help developers validate their implementation.Optional enhancement – Add verification guidance:
// At the end of commonWebpackConfig function, optionally add: if (process.env.DEBUG_WEBPACK_CONFIG) { console.log("CSS Module loader options:", config.module.rules .filter(r => r.test?.test?.("example.module.css")) .flatMap(r => r.use?.filter(l => l.loader?.includes("css-loader"))) ) }This allows developers to run
DEBUG_WEBPACK_CONFIG=true yarn buildto verify the override took effect.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/v9_upgrade.md(1 hunks)
⏰ 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)
- GitHub Check: claude-review
🔇 Additional comments (1)
docs/v9_upgrade.md (1)
198-206: Clear and appropriately-scoped documentation of override mechanics.The key points section effectively reinforces the important safeguards and sets proper expectations (temporary solution with migration guidance). The progression from simple YAML configuration → advanced webpack override → full migration aligns well with typical user needs and decision-making flow.
|
@claude review this PR. |
|
Claude Code is working… I'll analyze this and get back to you. |
|
@claude review this PR |
|
Claude finished @justin808's task —— View job PR Review CompleteTasks
Review FeedbackThis is an excellent documentation improvement that addresses issue #809 comprehensively. The additions provide exactly what users need to restore v8 CSS Modules behavior during migration. Strengths1. Complete, Copy-Paste Solution
2. Clear Technical Accuracy
3. Well-Structured Guidance
4. Proper Integration
Minor Suggestions1. Consider Adding Debugging Tip // Optional: Verify the override is applied during build
if (process.env.DEBUG_WEBPACK_CONFIG) {
console.log("CSS Module loader options:", JSON.stringify(
config.module.rules
.filter(r => r.test?.test?.("example.module.css"))
.flatMap(r => r.use?.filter(l => l.loader?.includes("css-loader"))),
null, 2
))
}This would allow users to run 2. File Path Clarity Technical ValidationI verified the code against:
The example should work correctly for users upgrading from v8 to v9. CodeRabbit Feedback AddressedCodeRabbit's review suggested adding verification guidance (similar to my suggestion #1 above), which is a valid enhancement but not blocking for merge. The current PR fully addresses issue #809's requirements. RecommendationApprove and merge. This is a high-quality documentation improvement that will significantly help users with large codebases migrate to v9. The suggestions above are optional enhancements that could be added in a follow-up PR if desired. The documentation is:
Great work addressing issue #809! |
Enhanced the webpack configuration override example with: - Clear instructions on where to create the config file - Reference to webpack configuration documentation - Debugging snippet to verify the override works - Example command to run with debug output This makes it easier for users to verify their configuration is correct and troubleshoot any issues. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
1 participant
Summary
Adds comprehensive backward compatibility documentation to the v9 upgrade guide, addressing issue #809. Users upgrading from Shakapacker 8.x to 9.x now have a complete working example showing how to restore the v8 CSS Modules behavior in large codebases.
Changes
Key Improvements
Problem Solved
The previous documentation mentioned overriding CSS Modules configuration but didn't provide a complete example. Users had to:
This led to runtime failures (components not rendering) that were difficult to debug since webpack builds succeeded but CSS classes were undefined at runtime.
Test Plan
Related
Generated with Claude Code
Summary by CodeRabbit