shakapacker 9.2.0 → 9.3.0.beta.0

data/docs/rspack.md

@@ -2,6 +2,8 @@
 
 Shakapacker supports [Rspack](https://rspack.rs) as an alternative assets bundler to Webpack. Rspack is a fast Rust-based web bundler with webpack-compatible API that can significantly speed up your build times.
 
+**📖 For configuration options, see the [Configuration Guide](./configuration.md)**
+
 ## Installation
 
 First, install the required Rspack dependencies:
@@ -10,7 +12,7 @@ First, install the required Rspack dependencies:
 npm install @rspack/core @rspack/cli -D
 # or
 yarn add @rspack/core @rspack/cli -D
-# or  
+# or
 pnpm add @rspack/core @rspack/cli -D
 # or
 bun add @rspack/core @rspack/cli -D
@@ -23,9 +25,8 @@ Note: These packages are already listed as optional peer dependencies in Shakapa
 To enable Rspack, update your `config/shakapacker.yml`:
 
 ```yaml
-default: &default
-  # ... other config options
-  assets_bundler: 'rspack'  # Change from 'webpack' to 'rspack'
+default: &default # ... other config options
+  assets_bundler: "rspack" # Change from 'webpack' to 'rspack'
 ```
 
 ### Configuration Files
@@ -33,7 +34,7 @@ default: &default
 Rspack uses its own configuration directory to keep things organized. Create your Rspack configuration file at `config/rspack/rspack.config.js`:
 
 ```javascript
-const { generateRspackConfig } = require('shakapacker/rspack')
+const { generateRspackConfig } = require("shakapacker/rspack")
 
 module.exports = generateRspackConfig()
 ```
@@ -43,14 +44,12 @@ module.exports = generateRspackConfig()
 If you need to customize your Rspack configuration:
 
 ```javascript
-const { generateRspackConfig } = require('shakapacker/rspack')
+const { generateRspackConfig } = require("shakapacker/rspack")
 
 const rspackConfig = generateRspackConfig({
-  plugins: [
-    new SomeRspackCompatiblePlugin()
-  ],
+  plugins: [new SomeRspackCompatiblePlugin()],
   resolve: {
-    extensions: ['.ts', '.tsx', '.js', '.jsx']
+    extensions: [".ts", ".tsx", ".js", ".jsx"]
   }
 })
 
@@ -62,14 +61,16 @@ module.exports = rspackConfig
 If you have an existing `config/webpack/webpack.config.js`, you can migrate it to `config/rspack/rspack.config.js`:
 
 **Old (webpack.config.js):**
+
 ```javascript
-const { generateWebpackConfig } = require('shakapacker')
+const { generateWebpackConfig } = require("shakapacker")
 module.exports = generateWebpackConfig()
 ```
 
 **New (rspack.config.js):**
+
 ```javascript
-const { generateRspackConfig } = require('shakapacker/rspack')
+const { generateRspackConfig } = require("shakapacker/rspack")
 module.exports = generateRspackConfig()
 ```
 
@@ -89,11 +90,11 @@ Rspack has built-in loaders that are faster than their webpack counterparts:
 
 Most webpack plugins work with Rspack, but some have Rspack-specific alternatives:
 
-| Webpack Plugin | Rspack Alternative | Status |
-|---|---|---|
-| `mini-css-extract-plugin` | `rspack.CssExtractRspackPlugin` | Built-in |
-| `copy-webpack-plugin` | `rspack.CopyRspackPlugin` | Built-in |
-| `terser-webpack-plugin` | `rspack.SwcJsMinimizerRspackPlugin` | Built-in |
+| Webpack Plugin            | Rspack Alternative                  | Status   |
+| ------------------------- | ----------------------------------- | -------- |
+| `mini-css-extract-plugin` | `rspack.CssExtractRspackPlugin`     | Built-in |
+| `copy-webpack-plugin`     | `rspack.CopyRspackPlugin`           | Built-in |
+| `terser-webpack-plugin`   | `rspack.SwcJsMinimizerRspackPlugin` | Built-in |
 
 ### Minification
 
@@ -136,28 +137,31 @@ The same dev server configuration in `shakapacker.yml` applies to both webpack a
 Rspack typically provides:
 
 - **2-10x faster** cold builds
-- **5-20x faster** incremental builds  
+- **5-20x faster** incremental builds
 - **Faster HMR** (Hot Module Replacement)
 - **Lower memory usage**
 
 ## Migration Checklist
 
 1. **Install Rspack dependencies:**
+
    ```bash
    npm install @rspack/core @rspack/cli -D
    ```
 
 2. **Update configuration:**
+
    ```yaml
    # config/shakapacker.yml
    default: &default
-     assets_bundler: 'rspack'
+     assets_bundler: "rspack"
    ```
 
 3. **Create Rspack config:**
+
    ```javascript
    // config/rspack/rspack.config.js
-   const { generateRspackConfig } = require('shakapacker/rspack')
+   const { generateRspackConfig } = require("shakapacker/rspack")
    module.exports = generateRspackConfig()
    ```
 
@@ -187,4 +191,4 @@ If builds are unexpectedly slow:
 
 - [Rspack Official Documentation](https://rspack.rs)
 - [Rspack Migration Guide](https://rspack.rs/guide/migration/webpack)
-- [Rspack Plugins](https://rspack.rs/plugins/webpack/)
+- [Rspack Plugins](https://rspack.rs/plugins/webpack/)

data/docs/rspack_migration_guide.md

@@ -2,10 +2,67 @@
 
 > 💡 **Quick Start**: For a step-by-step migration guide from Webpack to Rspack, see [Common Upgrades Guide - Webpack to Rspack](./common-upgrades.md#migrating-from-webpack-to-rspack).
 
+## Table of Contents
+
+- [Overview](#overview)
+- [Before You Migrate](#before-you-migrate)
+  - [Migration Timeline Expectations](#migration-timeline-expectations)
+  - [Testing Strategy](#testing-strategy)
+  - [Server-Side Rendering (SSR) Considerations](#server-side-rendering-ssr-considerations)
+- [Key Differences from Webpack](#key-differences-from-webpack)
+- [Migration Steps](#migration-steps)
+- [Configuration Best Practices](#configuration-best-practices)
+- [Common Issues and Solutions](#common-issues-and-solutions)
+- [Performance Tips](#performance-tips)
+- [Debugging Configuration](#debugging-configuration)
+- [Resources](#resources)
+
 ## Overview
 
 This guide documents the differences between webpack and Rspack configurations in Shakapacker, and provides migration guidance for users switching to Rspack.
 
+[Rspack](https://rspack.rs/) is a high-performance bundler written in Rust, offering 5-10x faster build times than webpack with excellent webpack compatibility.
+
+## Before You Migrate
+
+### Migration Timeline Expectations
+
+Based on real-world migrations, plan your migration time accordingly:
+
+- **Simple projects** (no SSR, no CSS modules, no custom config): 1-2 hours
+- **Standard projects** (CSS modules, basic SSR): 4-8 hours
+- **Complex projects** (CSS modules, SSR, ReScript, custom config): 2-3 days
+
+**Without good documentation**: A complex migration can take 3+ days with 11+ commits to resolve all issues.
+
+**With this documentation**: Most issues can be resolved in 2-3 commits.
+
+### Testing Strategy
+
+When migrating from webpack to Rspack, follow this testing strategy to minimize issues:
+
+1. **Test locally first**: Ensure you can run the full test suite locally before pushing
+2. **Incremental migration**: Consider migrating to SWC first (while on webpack), test thoroughly, then migrate to Rspack
+3. **Watch for test flakiness**: SSR-related issues (especially CSS extraction) can cause non-deterministic test failures
+4. **Run full test suite**: Don't rely solely on CI - run tests locally to catch issues faster
+
+### Server-Side Rendering (SSR) Considerations
+
+⚠️ **If your application uses SSR**, be aware of these critical issues before migrating:
+
+1. **CSS Extraction Differences**: Rspack uses different loader paths than webpack for CSS extraction
+2. **CSS Modules Breaking Change**: Shakapacker 9 changed from default exports to named exports
+3. **React Runtime Compatibility**: SWC's automatic runtime may not work with React on Rails SSR detection
+
+**SSR Migration Checklist** (complete before migrating):
+
+- [ ] Understand how your server bundle filters CSS extraction loaders
+- [ ] Know whether you're using CSS modules and how they're imported
+- [ ] Check if you're using React on Rails SSR (may need classic React runtime)
+- [ ] Plan for potential configuration changes to handle both webpack and Rspack paths
+
+**Detailed SSR solutions** are provided in the [Common Issues](#common-issues-and-solutions) section below.
+
 ## Key Differences from Webpack
 
 ### 1. Built-in Loaders
@@ -145,7 +202,7 @@ devServer: {
 }
 ```
 
-## Migration Checklist
+## Migration Steps
 
 ### Quick Start: Using the Switch Bundler Task
 
@@ -194,7 +251,7 @@ rails shakapacker:switch_bundler --init-config
 
 If you prefer to migrate manually or need more control:
 
-### Step 1: Update Dependencies
+#### Step 1: Update Dependencies
 
 ```bash
 # Remove webpack dependencies
@@ -204,7 +261,7 @@ npm uninstall webpack webpack-cli webpack-dev-server
 npm install --save-dev @rspack/core @rspack/cli
 ```
 
-### Step 2: Update Configuration Files
+#### Step 2: Update Configuration Files
 
 1. Create `config/rspack/rspack.config.js` based on your webpack config
 2. Update `config/shakapacker.yml`:
@@ -213,24 +270,24 @@ npm install --save-dev @rspack/core @rspack/cli
 assets_bundler: "rspack"
 ```
 
-### Step 3: Replace Loaders
+#### Step 3: Replace Loaders
 
 - Replace `babel-loader` with `builtin:swc-loader`
 - Remove `file-loader`, `url-loader`, `raw-loader` - use asset modules
 - Update CSS loaders to use Rspack's built-in support
 
-### Step 4: Update Plugins
+#### Step 4: Update Plugins
 
 - Replace plugins with Rspack alternatives (see table above)
 - Remove incompatible plugins
 - Add Rspack-specific plugins as needed
 
-### Step 5: TypeScript Setup
+#### Step 5: TypeScript Setup
 
 1. Add `isolatedModules: true` to `tsconfig.json`
 2. Optional: Add `ts-checker-rspack-plugin` for type checking
 
-### Step 6: Test Your Build
+#### Step 6: Test Your Build
 
 ```bash
 # Development build
@@ -240,26 +297,285 @@ bin/shakapacker
 bin/shakapacker --mode production
 ```
 
+#### Step 7: Review Migration Checklist
+
+- [ ] Install Rspack dependencies
+- [ ] Update `config/shakapacker.yml`
+- [ ] Create `config/rspack/rspack.config.js`
+- [ ] Replace incompatible plugins
+- [ ] Update TypeScript config (add `isolatedModules: true`)
+- [ ] Convert file loaders to asset modules
+- [ ] Test development build
+- [ ] Test production build
+- [ ] Run test suite
+- [ ] Update CI/CD pipelines
+- [ ] Deploy to staging
+- [ ] Monitor performance improvements
+
+## Configuration Best Practices
+
+### Configuration Organization
+
+**Recommended approach**: Keep webpack and rspack configs in the same directory with conditional logic:
+
+```javascript
+// config/webpack/webpack.config.js (works for both bundlers)
+const { config } = require("shakapacker")
+const bundler =
+  config.assets_bundler === "rspack"
+    ? require("@rspack/core")
+    : require("webpack")
+
+// Use for plugins
+clientConfig.plugins.push(
+  new bundler.ProvidePlugin({
+    /* ... */
+  })
+)
+
+serverConfig.plugins.unshift(
+  new bundler.optimize.LimitChunkCountPlugin({ maxChunks: 1 })
+)
+```
+
+**Avoid**: Creating separate `config/rspack/` directory unless configs diverge significantly.
+
+**Benefits**:
+
+- Smaller diff when comparing configurations
+- Easy to see what's different between bundlers
+- Single source of truth for webpack/rspack config
+- Easier maintenance and debugging
+
+### CSS Modules Configuration Placement
+
+**Critical**: CSS modules configuration overrides must be inside the config function:
+
+```javascript
+// ✅ CORRECT - Inside function (applied fresh each time)
+const commonWebpackConfig = () => {
+  const baseConfig = generateWebpackConfig()
+
+  baseConfig.module.rules.forEach((rule) => {
+    // Override CSS modules here
+  })
+
+  return merge({}, baseConfig, commonOptions)
+}
+
+// ❌ INCORRECT - Outside function (may not apply consistently)
+const baseConfig = generateWebpackConfig()
+baseConfig.module.rules.forEach((rule) => {
+  // This may not work correctly
+})
+```
+
+### Handling Breaking Changes
+
+When upgrading to Shakapacker 9 with Rspack:
+
+1. **CSS Modules default exports → named exports**: This is a breaking change. Either:
+   - Update your code to use named imports (recommended for new projects)
+   - Override the configuration to keep default exports (easier for existing large codebases)
+
+2. **Document your decisions**: Add comments explaining why you chose a particular configuration approach
+
+3. **Create patches for broken dependencies**: If ReScript or other compiled-to-JS dependencies are missing build configs, use `patch-package` and file upstream issues
+
+### Common Pitfalls to Avoid
+
+1. **Don't commit generated files**: Check your `.gitignore` for files that should not be committed (e.g., `i18n/translations.js`)
+2. **Update lockfiles**: Always run your package manager after adding dependencies (especially `patch-package`)
+3. **Test with frozen lockfile**: Ensure your CI runs with `--frozen-lockfile` or equivalent to catch lockfile issues
+4. **Check Node version compatibility**: Verify your Node version meets all dependency requirements
+5. **Don't make empty commits**: If CI fails but local passes, investigate the root cause - don't try to "trigger CI re-run" with empty commits
+
 ## Common Issues and Solutions
 
+### Issue: CSS Modules Returning Undefined (CRITICAL)
+
+**Error:** `Cannot read properties of undefined (reading 'className')` in SSR or `export 'default' (imported as 'css') was not found`
+
+**Root Cause:** Shakapacker 9 changed the default CSS Modules configuration to use named exports (`namedExport: true`), which is a breaking change from v8's default export behavior.
+
+**Solution:** If you want to keep the v8 default export behavior, override the CSS loader configuration:
+
+```javascript
+// config/webpack/commonWebpackConfig.js (or rspack equivalent)
+const { generateWebpackConfig, merge } = require("shakapacker")
+
+const commonWebpackConfig = () => {
+  const baseWebpackConfig = generateWebpackConfig()
+
+  // Override CSS modules to use default exports for backward compatibility
+  baseWebpackConfig.module.rules.forEach((rule) => {
+    if (rule.use && Array.isArray(rule.use)) {
+      const cssLoader = rule.use.find((loader) => {
+        const loaderName = typeof loader === "string" ? loader : loader?.loader
+        return loaderName?.includes("css-loader")
+      })
+
+      if (cssLoader?.options?.modules) {
+        cssLoader.options.modules.namedExport = false
+        cssLoader.options.modules.exportLocalsConvention = "camelCase"
+      }
+    }
+  })
+
+  return merge({}, baseWebpackConfig, commonOptions)
+}
+```
+
+**Important:** This configuration must be inside the function so it applies to fresh config each time.
+
+See [CSS Modules Export Mode](./css-modules-export-mode.md) for detailed migration guidance.
+
+### Issue: Server-Side Rendering CSS Extraction (CRITICAL for SSR)
+
+**Error:** Intermittent failures with `Cannot read properties of undefined (reading 'className')` or flaky tests
+
+**Root Cause:** When configuring server bundles, the code that removes CSS extraction loaders must handle both webpack and Rspack loader paths. Rspack uses `cssExtractLoader.js` instead of `mini-css-extract-plugin`.
+
+**Solution:** Update your server webpack config to filter both loader types:
+
+```javascript
+// config/webpack/serverWebpackConfig.js
+rule.use = rule.use.filter((item) => {
+  let testValue
+  if (typeof item === "string") {
+    testValue = item
+  } else if (typeof item.loader === "string") {
+    testValue = item.loader
+  }
+  // Handle both Webpack and Rspack CSS extract loaders
+  return !(
+    testValue?.match(/mini-css-extract-plugin/) ||
+    testValue?.includes("cssExtractLoader") || // Rspack loader path!
+    testValue === "style-loader"
+  )
+})
+```
+
+**Additional SSR Requirement:** When modifying CSS modules options for SSR, use spread operator to preserve common config:
+
+```javascript
+if (cssLoader && cssLoader.options && cssLoader.options.modules) {
+  // Preserve existing modules config but add exportOnlyLocals for SSR
+  cssLoader.options.modules = {
+    ...cssLoader.options.modules, // Preserve namedExport and other settings!
+    exportOnlyLocals: true
+  }
+}
+```
+
+### Issue: SWC React Runtime with SSR
+
+**Error:** `Invalid call to renderToString. Possibly you have a renderFunction...`
+
+**Root Cause:** React on Rails SSR detection logic expects a specific function signature that may not work with SWC's automatic React runtime.
+
+**Solution:** Use classic React runtime in your SWC configuration:
+
+```javascript
+// config/swc.config.js
+const customConfig = {
+  options: {
+    jsc: {
+      transform: {
+        react: {
+          runtime: "classic", // Changed from 'automatic' for SSR compatibility
+          refresh: env.isDevelopment && env.runningWebpackDevServer
+        }
+      }
+    }
+  }
+}
+```
+
+### Issue: ReScript Module Resolution
+
+**Error:** `Module not found: Can't resolve './Actions.bs.js'`
+
+**Solution:** Add `.bs.js` to your resolve extensions:
+
+```javascript
+const commonOptions = {
+  resolve: {
+    extensions: [".css", ".ts", ".tsx", ".bs.js"] // Add .bs.js for ReScript
+  }
+}
+```
+
+### Issue: ReScript Dependencies Missing Compiled Files
+
+**Error:** `Module not found: Can't resolve '@some-package/src/Module.bs.js'`
+
+**Root Cause:** Some ReScript packages ship only `.res` source files without compiled `.bs.js` files, or have broken `bsconfig.json` configurations.
+
+**Solution:** Use `patch-package` to fix the dependency:
+
+1. Install patch-package:
+
+```bash
+npm install --save-dev patch-package
+```
+
+2. Add postinstall script to `package.json`:
+
+```json
+{
+  "scripts": {
+    "postinstall": "patch-package"
+  }
+}
+```
+
+3. Fix the package's `bsconfig.json` (example for a package missing `package-specs`):
+
+```json
+{
+  "name": "@package/name",
+  "sources": ["src"],
+  "package-specs": [
+    {
+      "module": "esmodule",
+      "in-source": true
+    }
+  ],
+  "suffix": ".bs.js"
+}
+```
+
+4. Generate the patch:
+
+```bash
+npx patch-package @package/name
+```
+
+5. Consider filing an issue with the upstream package maintainer.
+
 ### Issue: LimitChunkCountPlugin Error
 
 **Error:** `Cannot read properties of undefined (reading 'tap')`
+
 **Solution:** Remove `webpack.optimize.LimitChunkCountPlugin` and use `splitChunks` configuration instead.
 
 ### Issue: Missing Loaders
 
 **Error:** Module parse errors
+
 **Solution:** Check console logs for skipped loaders and install missing dependencies.
 
 ### Issue: CSS Extraction
 
 **Error:** CSS not being extracted properly
+
 **Solution:** Use `rspack.CssExtractRspackPlugin` instead of `mini-css-extract-plugin`.
 
 ### Issue: TypeScript Errors
 
 **Error:** TypeScript compilation errors
+
 **Solution:** Ensure `isolatedModules: true` is set in `tsconfig.json`.
 
 ## Performance Tips
@@ -269,6 +585,16 @@ bin/shakapacker --mode production
 3. **Enable Caching:** Rspack has built-in persistent caching
 4. **Use SWC:** The built-in SWC loader is significantly faster than Babel
 
+**Expected Performance Improvements:**
+
+| Build Type       | Webpack | Rspack | Improvement |
+| ---------------- | ------- | ------ | ----------- |
+| Cold build       | 60s     | 8s     | 7.5x faster |
+| Hot reload       | 3s      | 0.5s   | 6x faster   |
+| Production build | 120s    | 15s    | 8x faster   |
+
+**Note:** Actual improvements vary based on project size, configuration, and hardware. Rspack's Rust-based architecture provides consistent 5-10x performance gains across most scenarios.
+
 ## Debugging Configuration
 
 To compare your webpack and rspack configurations during migration:
@@ -302,4 +628,5 @@ See the [Troubleshooting Guide](./troubleshooting.md#exporting-webpack--rspack-c
 - [Rspack Documentation](https://rspack.rs)
 - [Rspack Examples](https://github.com/rspack-contrib/rspack-examples)
 - [Awesome Rspack](https://github.com/rspack-contrib/awesome-rspack)
-- [Migration Guide](https://rspack.rs/guide/migration/webpack)
+- [Rspack Migration Guide](https://rspack.rs/guide/migration/webpack)
+- [Real-world Migration Example](https://github.com/shakacode/react-webpack-rails-tutorial/pull/680) - Complete migration from webpack to Rspack with SSR, CSS Modules, and ReScript

data/docs/sprockets.md

@@ -5,6 +5,7 @@
 If you are still using Sprockets for some of your assets, you might want to include files from `node_modules` directory in your asset pipeline. This is useful, for example, if you want to reference a stylesheet from a node package in your `.scss` stylesheet.
 
 In order to enable this, make sure you add `node_modules` to the asset load path by adding the following in an initializer (for example `config/initializers/assets.rb`)
+
 ```ruby
 Rails.application.config.assets.paths << Rails.root.join('node_modules')
 ```

data/docs/style_loader_vs_mini_css.md

@@ -21,15 +21,15 @@ style-loader is how you are probably are used to serving CSS in development with
 
 ### benefits
 
-* No [Flash Of Unstyled Content (FOUC)](https://en.wikipedia.org/wiki/Flash_of_unstyled_content) on HMR refreshes
-* Smaller/faster incremental updates.
+- No [Flash Of Unstyled Content (FOUC)](https://en.wikipedia.org/wiki/Flash_of_unstyled_content) on HMR refreshes
+- Smaller/faster incremental updates.
 
 ### drawbacks
 
-* Inflated JS deliverable size; requires JS execution before CSS is available
-* FOUC on initial page load
-* Adds an extra dependency
-* Divergence in delivery mechanism from production
+- Inflated JS deliverable size; requires JS execution before CSS is available
+- FOUC on initial page load
+- Adds an extra dependency
+- Divergence in delivery mechanism from production
 
 ## Why would I pick mini-css-extract-plugin?
 
@@ -37,12 +37,12 @@ mini-css-extract-plugin's behavior is much more true to a production deployment'
 
 ### benefits
 
-* Required for production, so it's going to be in play anyhow. Using only it simplifies the config and eliminates the style-loader dependency.
-* No FOUC on initial page loads
-* CSS delivered via `<link>` tags matches the mechanism used in production (I have been guilty of omitting my `stylesheet_pack_tag` for my first deploy because CSS worked fine with just the `javascript_pack_tag` in development.)
+- Required for production, so it's going to be in play anyhow. Using only it simplifies the config and eliminates the style-loader dependency.
+- No FOUC on initial page loads
+- CSS delivered via `<link>` tags matches the mechanism used in production (I have been guilty of omitting my `stylesheet_pack_tag` for my first deploy because CSS worked fine with just the `javascript_pack_tag` in development.)
 
 ### drawbacks
 
-* Invokes a separate HTTP request, compared to style-loader
-* Potential for FOUC on HMR refreshes
-* More data transferred per refresh (full stylesheet reload, rather than just an incremental patch). Not likely to be noticed for local development, but still a technical difference. This may only be the case [when you're using local CSS modules](https://github.com/webpack-contrib/mini-css-extract-plugin/blob/master/src/hmr/hotModuleReplacement.js#L267-L273).
+- Invokes a separate HTTP request, compared to style-loader
+- Potential for FOUC on HMR refreshes
+- More data transferred per refresh (full stylesheet reload, rather than just an incremental patch). Not likely to be noticed for local development, but still a technical difference. This may only be the case [when you're using local CSS modules](https://github.com/webpack-contrib/mini-css-extract-plugin/blob/master/src/hmr/hotModuleReplacement.js#L267-L273).

data/docs/subresource_integrity.md

@@ -1,13 +1,16 @@
 # Subresource integrity
+
 It's a cryptographic hash that helps browsers check that the served js or css file has not been tampered in any way.
 
 [MDN - Subresource Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity)
 
 ## Important notes
+
 - If you somehow modify the file after the hash was generated, it will automatically be considered as tampered, and the browser will not allow it to be executed.
 - Enabling subresource integrity generation, will change the structure of `manifest.json`. Keep that in mind if you utilize this file in any other custom implementation.
 
 Before:
+
 ```json
 {
   "application.js": "/path_to_asset"
@@ -15,6 +18,7 @@ Before:
 ```
 
 After:
+
 ```json
 {
   "application.js": {
@@ -25,6 +29,7 @@ After:
 ```
 
 ## Possible CORS issues
+
 Enabling subresource integrity for an asset, actually enforces CORS checks on that resource too. Which means that
 if you haven't set that up properly beforehand, it will probably lead to CORS errors with cached assets.
 
@@ -36,19 +41,20 @@ By default, this setting is disabled, to ensure backwards compatibility, and let
 This may change in the future, as it is a very nice security feature, and it should be enabled by default.
 
 To enable it, just add this in `shakapacker.yml`
+
 ```yml
-  integrity:
-    enabled: true    
+integrity:
+  enabled: true
 ```
 
-For further customization, you can also utilize the options `hash_functions` that control the functions used to generate 
+For further customization, you can also utilize the options `hash_functions` that control the functions used to generate
 integrity hashes. And `cross_origin` that sets the cross-origin loading attribute.
 
 ```yml
-  integrity:
-    enabled: true
-    hash_functions: ["sha256", "sha384", "sha512"]
-    cross_origin: "anonymous" # or "use-credentials"
+integrity:
+  enabled: true
+  hash_functions: ["sha256", "sha384", "sha512"]
+  cross_origin: "anonymous" # or "use-credentials"
 ```
 
 This will utilize under the hood webpack-subresource-integrity plugin and will modify `manifest.json` to include integrity hashes.