Fix prettier formatting issues from PR #1769

CHANGELOG.md

@@ -442,6 +442,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.
 
@@ -1159,11 +1160,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.
 

CODING_AGENTS.md

@@ -259,15 +259,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

docs/additional-details/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.

docs/getting-started.md

@@ -38,6 +38,7 @@ 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)
 

docs/guides/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

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

@@ -238,6 +238,7 @@ 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
@@ -251,6 +252,7 @@ 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
@@ -262,6 +264,7 @@ 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.:
 
     ```
@@ -291,6 +294,7 @@ 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,6 +57,7 @@ _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.
@@ -65,6 +66,7 @@ _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

spec/dummy/spec/fixtures/automated_packs_generation/components/ComponentWithCSSModule/ror_components/ComponentWithCSSModule.jsx

@@ -9,4 +9,4 @@ const ComponentWithCSSModule = () => {
   );
 };
 
-export default ComponentWithCSSModule;
+export default ComponentWithCSSModule;

spec/dummy/spec/fixtures/automated_packs_generation/components/ComponentWithCSSModule/ror_components/ComponentWithCSSModule.module.css

@@ -6,4 +6,4 @@
 .title {
   font-size: 2rem;
   font-weight: bold;
-}
+}