Add tests to validate CSS module handling in pack generator

[AbanoubGhadban]

Summary

Remove this paragraph and provide a general description of the code changes in your pull
request... were there any bugs you had fixed? If so, mention them. If
these bugs have open GitHub issues, be sure to tag them here as well,
to keep the conversation linked together.

Pull Request checklist

Remove this line after checking all the items here. If the item is not applicable to the PR, both check it out and wrap it by ~.

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

Add the CHANGELOG entry at the top of the file.

Other Information

Remove this paragraph and mention any other important and relevant information such as benchmarks.

---

This change is 

Summary by CodeRabbit

• Tests
  • Expanded specs for CSS module handling in component packs, confirming no CSS module pack files are generated and only the expected JavaScript pack is produced.
  • Improves confidence and reliability of asset generation behavior.
  • No user-facing changes or API updates.

[coderabbitai]

Walkthrough

Adds two RSpec tests to PacksGenerator specs to validate behavior when components use CSS modules. Tests assert that no CSS module pack files are generated and that only the JavaScript pack is present. Introduces a glob pattern for CSS module packs in the test.

Changes

Cohort / File(s)	Summary
PacksGenerator specs spec/dummy/spec/packs_generator_spec.rb	Added tests under "when component with CSS module" to assert absence of CSS module pack files and presence of only the JS pack; introduced css_module_pack_glob_pattern for matching *.module* files.

Sequence Diagram(s)

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• fixed css-loader instalation and css import in example files #1634 — Updates generator templates to include/import a CSS module; related to this PR’s tests around CSS module pack generation behavior.

Suggested reviewers

• Judahmeek

Pre-merge checks (2 passed, 1 warning)

❌ Failed checks (1 warning)

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

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title succinctly and accurately describes the main change—adding tests to validate CSS module handling in the pack generator—and is concise and specific enough for a reviewer scanning history to understand the primary change.

Poem

A nibble of specs, a hop through the trees,
No stray CSS packs, just JS, please.
I thump with delight, assertions align,
Modules stay quiet, the bundles are fine.
Hippity hooray—green checks, on the vine! 🥕🐇

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

• Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
• Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.

✨ Finishing touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch add-spec-for-ignoring-css-files-in-auto-bundling-directory

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[claude]

Code Review: Add tests to validate CSS module handling in pack generator

Overall Assessment

This PR adds two targeted tests to validate that CSS module files are properly handled by the pack generator. The tests are well-written and address an important edge case.

Code Quality and Best Practices ✅

Strengths:

• Clear test intent: Both test names clearly describe what behavior is being validated
• Appropriate test setup: Reuses existing test infrastructure and fixtures effectively
• Good use of glob patterns: The css_module_pack_glob_pattern variable uses a flexible glob pattern that can match various CSS module extensions (.module.css, .module.scss, etc.)
• Proper test isolation: Tests are scoped within the existing "when component with CSS module" context
• Follows existing conventions: Code style matches the surrounding test suite (RSpec syntax, variable naming, indentation)

Minor suggestions:

• The variable name css_module_pack_glob_pattern could be shortened to css_module_glob for brevity
• Consider adding a comment explaining why CSS modules shouldn't generate packs (for documentation)

Potential Issues ⚠️

Edge case handling:
The tests assume CSS modules always have the .module.* pattern, but should consider:

• What if there are multiple CSS-related files with different extensions?
• What about CSS modules with different naming conventions?

Test robustness:

• The second test ("only generates the js pack") is somewhat brittle as it relies on exact directory contents
• Consider making it more resilient to future additions of other generated files

Performance Considerations ✅

• Dir.glob() and Dir.entries() operations are lightweight for test fixtures
• Tests run efficiently within the existing context setup
• No performance concerns for this test addition

Security Concerns ✅

• No security issues identified
• Tests use safe file system operations
• No user input or external data processing involved

Test Coverage 🎯

Excellent coverage addition:

• Tests validate that CSS modules don't accidentally generate JavaScript packs
• Ensures the generator correctly filters out non-component files
• Complements existing tests for JavaScript variable name handling

Architecture Alignment ✅

• Tests fit well within the existing pack generator test structure
• Follows the established pattern of component-specific test contexts
• Aligns with the project's dual package structure (Ruby gem + NPM package)

Recommendations

1. Consider enhancing test robustness by checking for specific file types rather than exact directory contents
2. Add documentation comments explaining the business logic behind CSS module handling

Conclusion

This is a solid, focused PR that addresses a specific testing gap. The tests are well-implemented and will help prevent regressions in CSS module handling. The code quality is high and follows project conventions consistently.

Approved ✅ - This change enhances the test suite without introducing any risks.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

spec/dummy/spec/packs_generator_spec.rb (2)

441-441: Tighten the glob to only target JS packs.

Prevents false positives if non-JS artifacts (e.g., extracted CSS) ever end up in the generated dir.

-      let(:css_module_pack_glob_pattern) { "#{generated_directory}/#{component_name}.module*" }
+      let(:css_module_pack_glob_pattern) { "#{generated_directory}/#{component_name}.module*.js" }

---

478-481: Avoid brittle directory-wide equality; isolate to this component’s files.

The generated folder may contain other files (e.g., server bundle). Filter by component prefix to keep the test robust.

-      it "only generates the js pack" do
-        generated_files = Dir.entries(generated_directory).reject { |f| f.start_with?(".") }
-        expect(generated_files).to eq([File.basename(component_pack)])
-      end
+      it "only generates the js pack for this component" do
+        generated_files_for_component =
+          Dir.glob(File.join(generated_directory, "#{component_name}.*")).map { |f| File.basename(f) }
+        expect(generated_files_for_component).to eq([File.basename(component_pack)])
+      end

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b97c854 and 53095ac.

📒 Files selected for processing (1)

• spec/dummy/spec/packs_generator_spec.rb (2 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

spec/**/*.rb

📄 CodeRabbit inference engine (CLAUDE.md)

Ruby tests should be written for RSpec (project uses RSpec for Ruby testing)

Files:

• spec/dummy/spec/packs_generator_spec.rb

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

• GitHub Check: dummy-app-integration-tests (oldest)
• GitHub Check: dummy-app-integration-tests (newest)
• GitHub Check: build
• GitHub Check: rspec-package-tests (oldest)
• GitHub Check: rspec-package-tests (newest)
• GitHub Check: claude-review

🔇 Additional comments (2)

spec/dummy/spec/packs_generator_spec.rb (2)

473-473: No-op change.

Blank line only.

---

474-476: LGTM: explicit assertion that no CSS module pack is emitted.

Clear signal that CSS modules aren’t auto-bundled.

[claude]

Code Review Feedback

Overall Assessment

This PR adds valuable test coverage for CSS module handling in the pack generator. The changes are focused, well-structured, and follow the existing test patterns.

Code Quality ✅

• Good: Follows existing test conventions and naming patterns
• Good: Clear and descriptive test descriptions
• Good: Proper use of RSpec matchers and expectations
• Good: Added appropriate let variables for reusability

Test Coverage ✅

The two new tests provide excellent coverage for the CSS module functionality:

1. Negative test: Validates that CSS module files don't generate packs (prevents regression)
2. Positive test: Confirms only the expected JS pack is generated (validates correct behavior)

Technical Implementation ✅

Strengths:

• Robust glob pattern: css_module_pack_glob_pattern correctly matches any CSS module extension (.module.*)
• Proper file filtering: Using reject { |f| f.start_with?(".") } to exclude hidden files
• Clear assertions: Both tests have single, focused assertions

Minor Suggestions:

1. File filtering: The reject approach is good, but could be more explicit:

   generated_files = Dir.entries(generated_directory).reject { |f| f.start_with?(".") || File.directory?(File.join(generated_directory, f)) }

   This would also exclude any subdirectories if they exist.

2. Consider using match_array for more descriptive failures:

   expect(generated_files).to match_array([File.basename(component_pack)])

Security ✅

No security concerns - these are purely test additions that validate existing functionality.

Performance ✅

• Minimal performance impact
• Efficient use of Dir.glob and Dir.entries
• Tests run in appropriate context with proper setup

Best Practices ✅

• Follows RSpec conventions
• Consistent with existing test structure
• Good separation of concerns (one assertion per test)
• Appropriate use of let for shared test data

Potential Issues

None identified. The tests are well-implemented and should work reliably.

Recommendations

1. Ready to merge - This is a solid addition to the test suite
2. Consider running the full test suite to ensure no regressions
3. Update PR description - The current template text should be replaced with actual change description

Test Validation

The tests validate important behavior:

• CSS modules (like ComponentWithCSSModule.module.css) should NOT generate pack files
• Only the JavaScript component pack should be generated
• This prevents potential build issues and maintains clean generated asset structure

Great work on improving test coverage for this edge case! 🎯

[claude]

Code Review: Add tests to validate CSS module handling in pack generator

✅ Positives

1. Well-focused test additions: The new tests specifically validate that CSS module files (.module.*) don't generate their own pack files, which is the correct behavior since CSS modules should only be imported by JavaScript components.

2. Good test structure: The tests follow the existing pattern in the spec file with clear setup using stub_packer_source_path and descriptive assertions.

3. Appropriate assertion methods: Using Dir.glob(css_module_pack_glob_pattern) with be_empty and checking generated files with Dir.entries provides clear validation of the expected behavior.

🔍 Code Quality & Best Practices

Good practices observed:

• Tests are added within the existing context block for "component with CSS module"
• Clear variable naming (css_module_pack_glob_pattern, generated_files)
• Follows Ruby/RSpec conventions consistently

Minor suggestions:

• Consider extracting the glob pattern logic into a helper method if this pattern is used elsewhere
• The reject block could use a more descriptive variable name than 'f'

🐛 No Major Issues Found

The code logic is sound:

• The pack generator correctly filters component files using COMPONENT_EXTENSIONS regex in filter_component_files
• CSS module files (.module.css, .module.scss, etc.) don't match this regex, so they won't generate packs
• The tests validate this expected behavior appropriately

⚡ Performance Considerations

• File system operations (Dir.glob, Dir.entries) in tests are minimal and appropriate for validation
• No performance concerns for test code

🔒 Security Assessment

• No security concerns identified
• Tests only read from filesystem in expected directories
• No external inputs or user data involved

🧪 Test Coverage Assessment

Excellent coverage additions:

1. Negative test: Validates CSS module files don't generate packs (line 474-476)
2. Isolation test: Confirms only the expected JS pack is generated (line 478-481)

Test coverage is comprehensive - these additions fill an important gap by explicitly testing the CSS module handling behavior.

📋 Recommendations

1. PR Description: The PR template still contains placeholder text. Consider updating with:

   • Brief description of the specific CSS module handling being tested
   • Context about why these tests were needed

2. Minor code improvement (optional):
   Replace 'f' with 'file' for better readability in the reject block

3. Documentation: Consider adding a comment explaining why CSS modules shouldn't generate packs (they're imported by components, not standalone entry points).

✅ Approval Status

This PR is ready for merge after addressing the PR description. The code changes are solid, well-tested, and follow project conventions. The tests provide valuable validation of CSS module handling in the pack generator.

The implementation correctly validates that the PacksGenerator only processes JavaScript/TypeScript component files (matching COMPONENT_EXTENSIONS) and ignores CSS module files, which is the expected and desired behavior.

[claude]

Code Review

✅ Strengths

Test Coverage & Intent: These tests add valuable validation for CSS module handling in the pack generator, specifically ensuring that:

• CSS module files (.module.css) don't generate separate pack files
• Only the expected JavaScript pack is created

Code Quality: The tests follow existing patterns in the file and are well-structured.

📋 Observations

Test Structure: The new tests complement the existing CSS module tests nicely:

• Line 448: Tests for valid JavaScript variable names
• Line 462: Tests for syntax validity
• New: Lines 474-481 test file generation behavior

Implementation Details:

• Uses glob pattern matching for CSS module detection
• Filters out hidden files (starting with '.') appropriately
• Follows RSpec conventions with descriptive test names

🔍 Minor Suggestions

1. Variable Naming: The variable css_module_pack_glob_pattern is quite verbose. Consider css_module_glob for brevity while maintaining clarity.

2. Test Robustness: The second test assumes only one file should exist. Consider making it more explicit by using contain_exactly instead of eq for clearer expectations.

3. Test Independence: Good that the tests rely on the same before block as existing tests, ensuring consistency.

🎯 Overall Assessment

This is a solid addition that improves test coverage for CSS module handling. The tests are focused, follow established patterns, and validate important behavior that prevents regression in pack generation logic.

Approval: ✅ Ready to merge after addressing minor suggestions if desired.

---

Generated by Claude Code - Automated PR Review

[claude]

Code Review - PR #1775: Add tests to validate CSS module handling in pack generator

Overall Assessment

Good addition of test coverage for CSS module handling. The tests are well-structured and validate important behavior.

Code Quality ✅

Positive aspects:

• Clear and descriptive test names that explain the expected behavior
• Proper use of RSpec conventions and existing test patterns
• Consistent with existing test structure in the same context block
• Good use of let declarations for reusable test data

Style considerations:

• The new variable css_module_pack_glob_pattern follows existing naming conventions
• Proper use of glob patterns for file matching
• Tests follow the existing pattern of other context blocks in the file

Test Coverage ✅

Excellent test additions:

1. "does not generate a pack for a CSS module file" - Validates that .module.css files don't get individual pack files generated
2. "only generates the js pack" - Confirms only the expected JavaScript pack is created

Test validation:

• Uses Dir.glob() and Dir.entries() appropriately to check file system state
• Properly excludes dot files (. and ..) from the validation
• Uses be_empty matcher correctly for the glob pattern check

Security Considerations ✅

• No security concerns identified
• Tests only read from controlled test fixture directories
• No dynamic code execution or external resource access

Performance Considerations ✅

• Minimal performance impact - just adding two simple file system checks
• Efficient use of Dir.glob() and Dir.entries() for file validation
• No unnecessary file I/O operations

Potential Issues & Suggestions

Minor considerations:

1. Test isolation: The tests depend on the before block calling generate_packs_if_stale, which is good for consistency but consider documenting this dependency
2. Error handling: The tests assume the directory exists - consider what happens if generated_directory doesn't exist (though this is likely handled by the existing setup)

Enhancement suggestions:

1. Consider adding a test to verify the content of the generated JS pack doesn't include CSS module imports as separate components
2. The glob pattern *.module* is broad - consider being more specific like *.module.{css,scss,sass} if those are the only supported CSS module extensions

Missing Elements from PR Template

• PR description needs completion (currently shows template text)
• Changelog entry not added
• Documentation not updated (though may not be needed for internal tests)

Repository Conventions ✅

• Follows existing RSpec patterns in the codebase
• Consistent with the established test structure
• Properly placed in the existing context block for CSS module testing

Recommendation: APPROVE ✅

This PR effectively adds valuable test coverage for CSS module handling without introducing any risks. The tests are well-written and validate important edge cases in the pack generation logic.

Suggested next steps:

1. Complete the PR description
2. Consider the enhancement suggestions above for future iterations
3. Add a changelog entry if this fixes a previously reported issue

[claude]

Code Review

Overview

This PR adds valuable test coverage for CSS module handling in the pack generator, ensuring that CSS module files don't generate separate pack files and that only JavaScript packs are created.

Positive Aspects

Test Coverage Enhancement

• ✅ Adds comprehensive validation for CSS module handling behavior
• ✅ Tests both negative case (no CSS module packs) and positive case (only JS pack generated)
• ✅ Uses appropriate glob pattern matching for robust file detection

Code Quality

• ✅ Follows existing test patterns and naming conventions
• ✅ Clear, descriptive test names that explain the expected behavior
• ✅ Proper use of RSpec matchers (be_empty, eq)

Implementation

• ✅ Leverages existing test infrastructure and setup
• ✅ Uses meaningful variable names (css_module_pack_glob_pattern)
• ✅ Follows the established pattern of other test contexts in the file

Technical Analysis

Test 1: does not generate a pack for a CSS module file

• Uses Dir.glob(css_module_pack_glob_pattern) to search for any CSS module pack files
• The glob pattern captures various CSS module extensions appropriately
• Expectation be_empty is correct for this negative test case

Test 2: only generates the js pack

• Validates that exactly one file is generated (the JavaScript pack)
• Uses Dir.entries with proper filtering to exclude hidden files
• Compares against expected filename using File.basename

Minor Suggestions

1. Variable Positioning: Consider moving the css_module_pack_glob_pattern let declaration closer to where it's used, or add a comment explaining its purpose.

2. Pattern Specificity: The glob pattern might benefit from being more specific depending on supported CSS module file types.

Security & Performance

• ✅ No security concerns identified
• ✅ File system operations are appropriate for test context
• ✅ No performance issues - tests use efficient directory operations

Conclusion

This PR adds valuable regression protection for CSS module handling. The tests are well-written, follow project conventions, and provide clear validation of expected behavior. The changes enhance confidence in the pack generation system.

Recommendation: Approve ✅

The added test coverage is beneficial and the implementation is solid. This addresses an important aspect of the pack generator's behavior that should be tested.