Revert Prettier whitespace changes from markdown files

justin808 · claude · justin808 · commit 42ca9c5cde3e · 2025-11-09T22:23:50.000-10:00
Remove unnecessary whitespace-only changes from markdown files that were auto-formatted by Prettier during pre-commit hooks. These changes added noise to the PR without providing value. Only keeping the actual code fixes: - spec/react_on_rails/configuration_spec.rb - eslint.config.ts - bin/ci-switch-config 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
diff --git a/.claude/commands/update-changelog.md b/.claude/commands/update-changelog.md
@@ -5,6 +5,7 @@ You are helping to add an entry to the CHANGELOG.md file for the React on Rails
 ## Critical Requirements
 
 1. **User-visible changes only**: Only add changelog entries for user-visible changes:
+
    - New features
    - Bug fixes
    - Breaking changes
@@ -117,18 +118,21 @@ When a new version is released:
 ### For Regular Changelog Updates
 
 1. **ALWAYS fetch latest changes first**:
+
    - **CRITICAL**: Run `git fetch origin master` to ensure you have the latest commits
    - The workspace may be behind origin/master, causing you to miss recently merged PRs
    - After fetching, use `origin/master` for all comparisons, NOT local `master` branch
 
 2. **Determine the correct version tag to compare against**:
+
    - First, check the tag dates: `git log --tags --simplify-by-decoration --pretty="format:%ai %d" | head -10`
    - Find the latest version tag and its date
    - Compare origin/master branch date to the tag date
    - If the tag is NEWER than origin/master, it means the branch needs to be updated to include the tag's commits
    - **CRITICAL**: Always use `git log TAG..BRANCH` to find commits that are in the tag but not in the branch, as the tag may be ahead
 
 3. **Check commits and version boundaries**:
+
    - **IMPORTANT**: Use `origin/master` in all commands below, not local `master`
    - Run `git log --oneline LAST_TAG..origin/master` to see commits since the last release
    - Also check `git log --oneline origin/master..LAST_TAG` to see if the tag is ahead of origin/master
@@ -144,17 +148,20 @@ When a new version is released:
 5. **Read the current CHANGELOG.md** to understand the existing structure and formatting.
 
 6. **Determine where entries should go**:
+
    - If the latest version tag is NEWER than origin/master branch, move entries from "Unreleased" to that version section
    - If origin/master is ahead of the latest tag, add new entries to "Unreleased"
    - Always verify the version date in CHANGELOG.md matches the actual tag date
 
 7. **Add or move entries** to the appropriate section under appropriate category headings.
+
    - **CRITICAL**: When moving entries from "Unreleased" to a version section, merge them with existing entries under the same category heading
    - **NEVER create duplicate section headings** (e.g., don't create two "### Fixed" sections)
    - If the version section already has a category heading (e.g., "### Fixed"), add the moved entries to that existing section
    - Maintain the category order as defined above
 
 8. **Verify formatting**:
+
    - Bold description with period
    - Proper PR link (NO hash symbol)
    - Proper author link
@@ -174,10 +181,12 @@ When a new version is released:
 When releasing from beta to a stable version (e.g., v16.1.0-beta.3 → v16.1.0):
 
 1. **Remove all beta version labels** from the changelog:
+
    - Change `### [v16.1.0-beta.1]`, `### [v16.1.0-beta.2]`, etc. to a single `### [v16.1.0]` section
    - Combine all beta entries into the stable release section
 
 2. **Consolidate duplicate entries**:
+
    - If bug fixes or changes were made to features introduced in earlier betas, keep only the final state
    - Remove redundant changelog entries for fixes to beta features
    - Keep the most recent/accurate description of each change
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -38,6 +38,7 @@ Changes since the last non-beta release.
 #### Changed
 
 - **Shakapacker 9.0.0 Upgrade**: Upgraded Shakapacker from 8.2.0 to 9.0.0 with Babel transpiler configuration for compatibility. Key changes include:
+
   - Configured `javascript_transpiler: babel` in shakapacker.yml (Shakapacker 9.0 defaults to SWC which has PropTypes handling issues)
   - Added precompile hook support via `bin/shakapacker-precompile-hook` for ReScript builds and pack generation
   - Configured CSS Modules to use default exports (`namedExport: false`) for backward compatibility with existing `import styles from` syntax
@@ -99,6 +100,7 @@ To migrate to React on Rails Pro:
 **Note:** If you're not using any of the Pro-only methods listed above, no changes are required.
 
 - **Pro-Specific Configurations Moved to Pro Gem**: The following React Server Components (RSC) configurations have been moved from `ReactOnRails.configure` to `ReactOnRailsPro.configure`:
+
   - `rsc_bundle_js_file` - Path to the RSC bundle file
   - `react_server_client_manifest_file` - Path to the React server client manifest
   - `react_client_manifest_file` - Path to the React client manifest
@@ -124,6 +126,7 @@ To migrate to React on Rails Pro:
   See the [React on Rails Pro Configuration docs](https://github.com/shakacode/react_on_rails/blob/master/react_on_rails_pro/docs/configuration.md) for more details.
 
 - **Streaming View Helpers Moved to Pro Gem**: The following view helpers have been removed from the open-source gem and are now only available in React on Rails Pro:
+
   - `stream_react_component` - Progressive SSR using React 18+ streaming
   - `rsc_payload_react_component` - RSC payload rendering
 
@@ -148,10 +151,12 @@ To migrate to React on Rails Pro:
 #### New Features
 
 - **Server Bundle Security**: Added new configuration options for enhanced server bundle security and organization:
+
   - `server_bundle_output_path`: Configurable directory (relative to the Rails root) for server bundle output (default: "ssr-generated"). If set to `nil`, the server bundle will be loaded from the same public directory as client bundles. [PR 1798](https://github.com/shakacode/react_on_rails/pull/1798) by [justin808](https://github.com/justin808)
   - `enforce_private_server_bundles`: When enabled, ensures server bundles are only loaded from private directories outside the public folder (default: false for backward compatibility) [PR 1798](https://github.com/shakacode/react_on_rails/pull/1798) by [justin808](https://github.com/justin808)
 
 - **Improved Bundle Path Resolution**: Bundle path resolution for server bundles now works as follows:
+
   - If `server_bundle_output_path` is set, the server bundle is loaded from that directory.
   - If `server_bundle_output_path` is not set, the server bundle falls back to the client bundle directory (typically the public output path).
   - If `enforce_private_server_bundles` is enabled:
@@ -263,6 +268,7 @@ See [Release Notes](docs/release-notes/16.0.0.md) for complete migration guide.
 
 - **`defer_generated_component_packs` deprecated** → use `generated_component_packs_loading_strategy`
 - Migration:
+
   - `defer_generated_component_packs: true` → `generated_component_packs_loading_strategy: :defer`
   - `defer_generated_component_packs: false` → `generated_component_packs_loading_strategy: :sync`
   - Recommended: `generated_component_packs_loading_strategy: :async` for best performance
@@ -671,6 +677,7 @@ 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.
 
@@ -1388,11 +1395,13 @@ 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.
 
diff --git a/CODING_AGENTS.md b/CODING_AGENTS.md
@@ -260,15 +260,18 @@ Use `gh pr create` with:
 ## Debugging Workflow
 
 1. **Understand the Problem**
+
    - Read the issue carefully
    - Reproduce the bug if possible
    - Identify root cause
 
 2. **Create Minimal Test Case**
+
    - Write failing test that demonstrates issue
    - Keep it focused and minimal
 
 3. **Implement Fix**
+
    - Make smallest change possible
    - Ensure fix doesn't break existing functionality
    - Follow existing code patterns
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -607,18 +607,22 @@ This approach:
 **Common Issues and Solutions:**
 
 1. **React components not rendering (empty divs)**
+
    - **Cause**: Missing yalc setup for JavaScript package
    - **Solution**: Follow yalc setup steps above after running generator
 
 2. **Generator fails with Shakapacker errors**
+
    - **Cause**: Conflicting Shakapacker versions or incomplete installation
    - **Solution**: Clean reset and ensure consistent Shakapacker version across tests
 
 3. **Babel configuration conflicts during yalc development**
+
    - **Cause**: Both `babel.config.js` and `package.json` "babel" section defining presets
    - **Solution**: Remove "babel" section from `package.json`, keep only `babel.config.js`
 
 4. **"Package.json not found" errors**
+
    - **Cause**: Generator trying to access non-existent package.json files
    - **Solution**: Test with commits that fix this specific issue (e.g., bc69dcd0)
 
diff --git a/TODO.md b/TODO.md
@@ -59,11 +59,13 @@
 ## Developer Experience
 
 - [ ] **bin/dev help command enhancements**
+
   - [x] Add emojis and colors for better readability
   - [ ] Add section about component development patterns
   - [ ] Include troubleshooting for client/server split issues
 
 - [ ] **Babel Configuration Conflict Detection**
+
   - [ ] Add validation in generator/initializer to detect conflicting Babel configs
   - [ ] Improve error messaging for duplicate preset issues
   - [ ] Common conflict: babel.config.js + package.json "babel" section
diff --git a/docs/CI_OPTIMIZATION.md b/docs/CI_OPTIMIZATION.md
@@ -197,6 +197,7 @@ Claude will:
    ```
 
 3. **Separate doc changes from code changes:**
+
    - Docs-only PRs skip CI entirely
    - Mixed PRs run full CI
 
@@ -207,11 +208,13 @@ Claude will:
 ### For Maintainers
 
 1. **Monitor CI performance:**
+
    - Check GitHub Actions usage
    - Identify slow tests
    - Adjust matrix as needed
 
 2. **Update path filters:**
+
    - Add new file patterns as project evolves
    - Keep filters accurate
 
diff --git a/docs/DIRECTORY_LICENSING.md b/docs/DIRECTORY_LICENSING.md
@@ -78,6 +78,7 @@ react_on_rails/ (monorepo root)
 ### Package-Level Compliance
 
 1. **Gemspec Files**:
+
    - `react_on_rails.gemspec`: `s.license = "MIT"`
    - `react_on_rails_pro.gemspec`: `s.license = "UNLICENSED"`
 
diff --git a/docs/LICENSING_FAQ.md b/docs/LICENSING_FAQ.md
@@ -7,6 +7,7 @@
 **A:** Nothing changes for end users! We'll maintain the same dual licensing structure:
 
 - **MIT Licensed (Free & Open Source):**
+
   - `react_on_rails` Ruby gem
   - `react-on-rails` NPM package
   - Core functionality remains completely free
diff --git a/docs/MONOREPO_MERGER_PLAN.md b/docs/MONOREPO_MERGER_PLAN.md
@@ -660,10 +660,12 @@ After the initial merge, the following CI adjustments may be needed:
 ### Critical License Rules
 
 1. **Directory Classification:**
+
    - **MIT Licensed:** `lib/react_on_rails/` (including specs), `packages/react-on-rails/` (including tests)
    - **Pro Licensed:** All directories explicitly listed in LICENSE.md under "React on Rails Pro License"
 
 2. **LICENSE.md Updates:**
+
    - Must be updated whenever pro directories are moved or renamed
    - Must accurately reflect current directory structure
    - Pro directories must be explicitly listed
diff --git a/docs/building-features/streaming-server-rendering.md b/docs/building-features/streaming-server-rendering.md
@@ -119,6 +119,7 @@ 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)
@@ -164,11 +165,13 @@ 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
diff --git a/docs/contributor-info/releasing.md b/docs/contributor-info/releasing.md
@@ -19,14 +19,17 @@ rake release[version,dry_run,registry,skip_push]
 **Arguments:**
 
 1. **`version`** (required): Version bump type or explicit version
+
    - Bump types: `patch`, `minor`, `major`
    - Explicit: `16.2.0`
    - Pre-release: `16.2.0.beta.1` (rubygem format with dots, converted to `16.2.0-beta.1` for NPM)
 
 2. **`dry_run`** (optional): `true` to preview changes without releasing
+
    - Default: `false`
 
 3. **`registry`** (optional): Publishing registry for testing
+
    - `verdaccio`: Publish all NPM packages to local Verdaccio (skips RubyGems)
    - `npm`: Normal release to npmjs.org + rubygems.org (default)
 
@@ -208,6 +211,7 @@ Before releasing to production, test the release process locally:
    ```
 
 3. This will:
+
    - Publish all 3 NPM packages to local Verdaccio
    - Skip RubyGem publishing
    - Update version files (revert manually after testing)
@@ -237,10 +241,12 @@ This shows you exactly what would be updated without making any changes.
 If the release fails partway through (e.g., during NPM publish):
 
 1. Check what was published:
+
    - NPM: `npm view react-on-rails@X.Y.Z`
    - RubyGems: `gem list react_on_rails -r -a`
 
 2. If the git tag was created but packages weren't published:
+
    - Delete the tag: `git tag -d vX.Y.Z && git push origin :vX.Y.Z`
    - Revert the version commit: `git reset --hard HEAD~1 && git push -f`
    - Start over with `rake release[X.Y.Z]`
diff --git a/docs/migrating/migrating-from-react-rails.md b/docs/migrating/migrating-from-react-rails.md
@@ -3,16 +3,19 @@
 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.
diff --git a/docs/planning/docs-improvement/01-problem-analysis.md b/docs/planning/docs-improvement/01-problem-analysis.md
diff --git a/docs/planning/docs-improvement/02-pr-1813-comparison.md b/docs/planning/docs-improvement/02-pr-1813-comparison.md
diff --git a/docs/planning/docs-improvement/04-ia-redesign-plan.md b/docs/planning/docs-improvement/04-ia-redesign-plan.md
diff --git a/docs/planning/docs-improvement/ia-redesign-live.md b/docs/planning/docs-improvement/ia-redesign-live.md
diff --git a/docs/upgrading/release-notes/16.0.0.md b/docs/upgrading/release-notes/16.0.0.md
diff --git a/docs/upgrading/upgrading-react-on-rails.md b/docs/upgrading/upgrading-react-on-rails.md
