Unify bin/dev script and improve cleaning logic

- Replace bin/dev-static with unified bin/dev script supporting multiple modes
- Add targeted cleaning to remove only non-generated files from pack directories
- Refactor cleaning methods to reduce complexity per RuboCop suggestions
- Update all documentation to reference 'bin/dev static' instead of 'bin/dev-static'
- Remove obsolete dev-static generator file and associated tests

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

Co-Authored-By: Claude <noreply@anthropic.com>

Author: justin808

CHANGELOG.md

@@ -442,7 +442,6 @@ for details.
 - Removal of config.symlink_non_digested_assets_regex as it's no longer needed with rails/webpacker.
   If any business needs this, we can move the code to a separate gem.
 - Added configuration option `same_bundle_for_client_and_server` with default `false` because
-
   1. Production applications would typically have a server bundle that differs from the client bundle
   2. This change only affects trying to use HMR with react_on_rails with rails/webpacker.
 
@@ -1160,13 +1159,11 @@ No changes.
 - Added automatic compilation of assets at precompile is now done by ReactOnRails. Thus, you don't need to provide your own `assets.rake` file that does the precompilation.
   [#398](https://github.com/shakacode/react_on_rails/pull/398) by [robwise](https://github.com/robwise), [jbhatab](https://github.com/jbhatab), and [justin808](https://github.com/justin808).
 - **Migration to v6**
-
   - Do not run the generator again if you've already run it.
 
   - See [shakacode/react-webpack-rails-tutorial/pull/287](https://github.com/shakacode/react-webpack-rails-tutorial/pull/287) for an example of upgrading from v5.
 
   - To configure the asset compilation you can either
-
     1. Specify a `config/react_on_rails` setting for `build_production_command` to be nil to turn this feature off.
     2. Specify the script command you want to run to build your production assets, and remove your `assets.rake` file.
 

CODING_AGENTS.md

@@ -5,6 +5,7 @@ This guide provides specific guidelines for AI coding agents (like Claude Code)
 ## Quick Reference Commands
 
 ### Essential Commands
+
 ```bash
 # Install dependencies
 bundle && yarn
@@ -13,7 +14,7 @@ bundle && yarn
 bundle exec rspec                    # All tests (from project root)
 cd spec/dummy && bundle exec rspec   # Dummy app tests only
 
-# Linting & Formatting  
+# Linting & Formatting
 bundle exec rubocop                  # Ruby linting
 bundle exec rubocop [file_path]     # Lint specific file
 # Note: yarn format requires local setup, format manually
@@ -23,6 +24,7 @@ cd spec/dummy && foreman start       # Start dummy app with webpack
 ```
 
 ### CI Compliance Checklist
+
 - [ ] `bundle exec rubocop` passes with no offenses
 - [ ] All RSpec tests pass
 - [ ] No trailing whitespace
@@ -32,23 +34,27 @@ cd spec/dummy && foreman start       # Start dummy app with webpack
 ## Development Patterns for AI Contributors
 
 ### 1. Task Management
+
 Always use TodoWrite tool for multi-step tasks to:
+
 - Track progress transparently
 - Show the user what's being worked on
 - Ensure no steps are forgotten
 - Mark tasks complete as you finish them
 
 ```markdown
 Example workflow:
+
 1. Analyze the problem
 2. Create test cases
-3. Implement the fix  
+3. Implement the fix
 4. Run tests
 5. Fix linting issues
 6. Update documentation
 ```
 
 ### 2. Test-Driven Development
+
 When fixing bugs or adding features:
 
 1. **Create failing tests first** that reproduce the issue
@@ -57,13 +63,15 @@ When fixing bugs or adding features:
 4. **Verify all existing tests still pass**
 
 ### 3. File Processing Guidelines
+
 When working with file generation or processing:
 
 - **Filter by extension**: Only process relevant files (e.g., `.js/.jsx/.ts/.tsx` for React components)
 - **Validate assumptions**: Don't assume all files in a directory are components
 - **Handle edge cases**: CSS modules, config files, etc. should be excluded appropriately
 
 Example from CSS module fix:
+
 ```ruby
 COMPONENT_EXTENSIONS = /\.(jsx?|tsx?)$/
 
@@ -77,15 +85,17 @@ end
 ### Common Fixes
 
 1. **Trailing Whitespace**
+
    ```ruby
    # Bad
-   let(:value) { "test" }    
-   
-   # Good  
+   let(:value) { "test" }
+
+   # Good
    let(:value) { "test" }
    ```
 
 2. **Line Length (120 chars max)**
+
    ```ruby
    # Bad
    expect { eval(pack_content.gsub(/import.*from.*['"];/, "").gsub(/ReactOnRails\.register.*/, "")) }.not_to raise_error
@@ -97,11 +107,12 @@ end
    ```
 
 3. **Named Subjects (RSpec)**
+
    ```ruby
    # Bad
    describe "#method_name" do
      subject { instance.method_name(arg) }
-     
+
      it "does something" do
        expect(subject).to eq "result"
      end
@@ -110,14 +121,15 @@ end
    # Good
    describe "#method_name" do
      subject(:method_result) { instance.method_name(arg) }
-     
+
      it "does something" do
        expect(method_result).to eq "result"
      end
    end
    ```
 
 4. **Security/Eval Violations**
+
    ```ruby
    # Bad
    expect { eval(dangerous_code) }.not_to raise_error
@@ -130,6 +142,7 @@ end
    ```
 
 ### RuboCop Workflow
+
 1. Run `bundle exec rubocop [file]` to see violations
 2. Fix violations manually or with auto-correct where safe
 3. Re-run to verify fixes
@@ -138,15 +151,16 @@ end
 ## Testing Best Practices
 
 ### Test Structure
+
 ```ruby
 describe "FeatureName" do
   context "when condition A" do
     let(:setup) { create_test_condition }
-    
+
     before do
       # Setup code
     end
-    
+
     it "does expected behavior" do
       # Arrange, Act, Assert
     end
@@ -155,11 +169,13 @@ end
 ```
 
 ### Test Fixtures
+
 - Create realistic test data that represents edge cases
 - Use descriptive names for fixtures and variables
 - Clean up after tests (handled by RSpec automatically in most cases)
 
 ### CSS Module Testing Example
+
 ```ruby
 # Create test fixtures
 Write.create("ComponentWithCSSModule.module.css", css_content)
@@ -175,6 +191,7 @@ end
 ## Git & PR Workflow
 
 ### Branch Management
+
 ```bash
 git checkout -b fix/descriptive-name
 # Make changes
@@ -189,11 +206,12 @@ git push -u origin fix/descriptive-name
 ```
 
 ### Commit Message Format
+
 ```
 Brief description of the change
 
 - Detailed bullet points of what changed
-- Why the change was needed  
+- Why the change was needed
 - Any breaking changes or considerations
 
 Fixes #issue_number
@@ -204,7 +222,9 @@ Co-Authored-By: Claude <noreply@anthropic.com>
 ```
 
 ### PR Creation
+
 Use `gh pr create` with:
+
 - Clear title referencing the issue
 - Comprehensive description with summary and test plan
 - Link to the issue being fixed
@@ -213,21 +233,25 @@ Use `gh pr create` with:
 ## Common Pitfalls & Solutions
 
 ### 1. File Path Issues
+
 - Always use absolute paths in tools
 - Check current working directory with `pwd`
 - Use proper path joining methods
 
 ### 2. Test Environment
+
 - Run tests from correct directory (often project root)
 - Understand the difference between gem tests vs dummy app tests
 - Clean up test artifacts appropriately
 
 ### 3. Dependency Management
+
 - Don't assume packages are installed globally
 - Use `bundle exec` for Ruby commands
 - Verify setup with `bundle && yarn` when needed
 
 ### 4. RuboCop Configuration
+
 - Different rules may apply to different directories
 - Use `bundle exec rubocop` (not global rubocop)
 - Check `.rubocop.yml` files for project-specific rules
@@ -248,7 +272,7 @@ Use `gh pr create` with:
    - Ensure fix doesn't break existing functionality
    - Follow existing code patterns
 
-4. **Verify Solution** 
+4. **Verify Solution**
    - All new tests pass
    - All existing tests still pass
    - RuboCop compliance maintained
@@ -257,6 +281,7 @@ Use `gh pr create` with:
 ## IDE Configuration for AI Context
 
 When analyzing codebases, ignore these directories to avoid confusion:
+
 - `/coverage`, `/tmp`, `/gen-examples`
 - `/node_package/lib`, `/node_modules`
 - `/spec/dummy/app/assets/webpack`
@@ -266,7 +291,7 @@ When analyzing codebases, ignore these directories to avoid confusion:
 ## Communication with Human Maintainers
 
 - Be transparent about AI-generated changes
-- Explain reasoning behind implementation choices  
+- Explain reasoning behind implementation choices
 - Ask for clarification when requirements are ambiguous
 - Provide comprehensive commit messages and PR descriptions
 - Include test plans and verification steps
@@ -281,4 +306,4 @@ When analyzing codebases, ignore these directories to avoid confusion:
 
 ---
 
-This guide evolves based on AI contributor experiences. Suggest improvements via issues or PRs!
+This guide evolves based on AI contributor experiences. Suggest improvements via issues or PRs!

docs/additional-details/migrating-from-react-rails.md

@@ -3,19 +3,16 @@
 In this guide, it is assumed that you have upgraded the `react-rails` project to use `shakapacker` version 7. To this end, check out [Shakapacker v7 upgrade guide](https://github.com/shakacode/shakapacker/tree/master/docs/v7_upgrade.md). Upgrading `react-rails` to version 3 can make the migration smoother but it is not required.
 
 1. Update Deps
-
    1. Replace `react-rails` in `Gemfile` with the latest version of `react_on_rails` and run `bundle install`.
    2. Remove `react_ujs` from `package.json` and run `yarn install`.
    3. Commit changes!
 
 2. Run `rails g react_on_rails:install` but do not commit the change. `react_on_rails` installs node dependencies and also creates sample React component, Rails view/controller, and updates `config/routes.rb`.
 
 3. Adapt the project: Check the changes and carefully accept, reject, or modify them as per your project's needs. Besides changes in `config/shakapacker` or `babel.config` which are project-specific, here are the most noticeable changes to address:
-
    1. Check Webpack config files at `config/webpack/*`. If coming from `react-rails` v3, the changes are minor since you have already made separate configurations for client and server bundles. The most important change here is to notice the different names for the server bundle entry file. You may choose to stick with `server_rendering.js` or use `server-bundle.js` which is the default name in `react_on_rails`. The decision made here affects the other steps.
 
    2. In `app/javascript` directory you may notice some changes.
-
       1. `react_on_rails` by default uses `bundles` directory for the React components. You may choose to rename `components` into `bundles` to follow the convention.
 
       2. `react_on_rails` uses `client-bundle.js` and `server-bundle.js` instead of `application.js` and `server_rendering.js`. There is nothing special about these names. It can be set to use any other name (as mentioned above). If you too choose to follow the new names, consider updating the relevant `javascript_pack_tag` in your Rails views.

docs/getting-started.md

@@ -38,9 +38,8 @@ You may need to check [the instructions for installing into an existing Rails ap
    ```
 
 3. Start the app:
-
    - Run `./bin/dev` for HMR
-   - Run `./bin/dev-static` for statically created bundles (no HMR)
+   - Run `./bin/dev static` for statically created bundles (no HMR)
 
 4. Visit http://localhost:3000/hello_world.
 

docs/guides/streaming-server-rendering.md

@@ -119,7 +119,6 @@ You can test your application by running `rails server` and navigating to the ap
 When a user visits the page, they'll experience the following sequence:
 
 1. The initial HTML shell is sent immediately, including:
-
    - The page layout
    - Any static content (like the `<h1>` and footer)
    - Placeholder content for the React component (typically a loading state)
@@ -165,13 +164,11 @@ Streaming SSR is particularly valuable in specific scenarios. Here's when to con
 ### Ideal Use Cases
 
 1. **Data-Heavy Pages**
-
    - Pages that fetch data from multiple sources
    - Dashboard-style layouts where different sections can load independently
    - Content that requires heavy processing or computation
 
 2. **Progressive Enhancement**
-
    - When you want users to see and interact with parts of the page while others load
    - For improving perceived performance on slower connections
    - When different parts of your page have different priority levels

docs/guides/tutorial.md

@@ -134,7 +134,7 @@ Then run the server with one of the following options:
 ```bash
 ./bin/dev # For HMR
 # or
-./bin/dev-static # Without HMR, statically creating the bundles
+./bin/dev static # Without HMR, statically creating the bundles
 ```
 
 Visit [http://localhost:3000/hello_world](http://localhost:3000/hello_world) and see your **React On Rails** app running!

docs/guides/upgrading-react-on-rails.md

@@ -238,10 +238,8 @@ const { output } = webpackConfigLoader(configPath);
 For an example of upgrading, see [react-webpack-rails-tutorial/pull/416](https://github.com/shakacode/react-webpack-rails-tutorial/pull/416).
 
 - Breaking Configuration Changes
-
   1. Added `config.node_modules_location` which defaults to `""` if Webpacker is installed. You may want to set this to `'client'` in `config/initializers/react_on_rails.rb` to keep your `node_modules` inside the `/client` directory.
   2. Renamed
-
      - config.npm_build_test_command ==> config.build_test_command
      - config.npm_build_production_command ==> config.build_production_command
 
@@ -253,7 +251,6 @@ gem "webpacker"
 
 - Update for the renaming in the `WebpackConfigLoader` in your Webpack configuration.
   You will need to rename the following object properties:
-
   - webpackOutputPath ==> output.path
   - webpackPublicOutputDir ==> output.publicPath
   - hotReloadingUrl ==> output.publicPathWithHost
@@ -265,7 +262,6 @@ gem "webpacker"
   - devBuild ==> Use `const devBuild = process.env.NODE_ENV !== 'production';`
 
 - Edit your Webpack.config files:
-
   - Change your Webpack output to be like this. **Be sure to have the hash or chunkhash in the filename,** unless the bundle is server side.:
 
     ```
@@ -295,7 +291,6 @@ gem "webpacker"
     ```
 
 - Find your `webpacker_lite.yml` and rename it to `webpacker.yml`
-
   - Consider copying a default webpacker.yml setup such as https://github.com/shakacode/react-on-rails-v9-rc-generator/blob/master/config/webpacker.yml
   - If you are not using the webpacker Webpack setup, be sure to put in `compile: false` in the `default` section.
   - Alternately, if you are updating from webpacker_lite, you can manually change these:

docs/release-notes/15.0.0.md

@@ -57,7 +57,6 @@ _The image above demonstrates the dramatic performance improvement:_
 - The `generated_component_packs_loading_strategy` defaults to `:async` for Shakapacker ≥ 8.2.0 and `:sync` for Shakapacker < 8.2.0.
 - The `force_load` configuration now defaults to `true`.
 - The new default values of `generated_component_packs_loading_strategy: :async` and `force_load: true` work together to optimize component hydration. Components now hydrate as soon as their code and server-rendered HTML are available, without waiting for the full page to load. This parallel processing significantly improves time-to-interactive by eliminating the traditional waterfall of waiting for page load before beginning hydration (It's critical for streamed HTML).
-
   - The previous need for deferring scripts to prevent race conditions has been eliminated due to improved hydration handling. Making scripts not defer is critical to execute the hydration scripts early before the page is fully loaded.
   - The `force_load` configuration makes `react-on-rails` hydrate components immediately as soon as their server-rendered HTML reaches the client, without waiting for the full page load.
   - If you want to keep the previous behavior, you can set `generated_component_packs_loading_strategy: :defer` or `force_load: false` in your `config/initializers/react_on_rails.rb` file.
@@ -66,7 +65,6 @@ _The image above demonstrates the dramatic performance improvement:_
     - You can override this behavior for individual Redux stores by calling the `redux_store` helper with `force_load: false`, same as `react_component`.
 
 - `ReactOnRails.reactOnRailsPageLoaded()` is now an async function:
-
   - If you manually call this function to ensure components are hydrated (e.g., with async script loading), you must now await the promise it returns:
 
     ```js