shakapacker 9.3.0.beta.1 → 9.3.0.beta.4

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: c503694d35261163ce77ef2efb38c85b5365c7e0c817f06d0c3a9b7e9cd8ce0e
-  data.tar.gz: 6bea7b663bdb25fc2428bba429ec2f773a4298e91c2fdf2af9b8d0be5f089dd1
+  metadata.gz: 2f2fafddfa10d364b8e62946786c16d9206ecffadf82b719e3ffeb2100608da0
+  data.tar.gz: 0e0cdc08d53e64e8066d7232aba1022b6a7708067d56ff7ba738803bfbc49a78
 SHA512:
-  metadata.gz: dca52dbb54ea99fd8ad7b3e5cc9de4f0c5446a5c7a2f855032355d5b224fc91e74055784e92733ac6b41548e9676b4ed76c1bf8f4e88d024d6984ddae79f49dd
-  data.tar.gz: 702f88a69f5116ab0bc2bbfbff2d650cc5d542dd71a4716e4083e1ef79785a0a1a3eeb734924f1753ecafbe633a9bc21d29d86c60911caa6fe6e14acc4531d95
+  metadata.gz: dcbb4604f956d78acaea611bb760ecea97a1afcc15bc390b9c5a64c5d9654f5d08e83c57ed24da55aca0a1a98da074a0047a754cadf5f74ee8ba832fb6e93b3e
+  data.tar.gz: 47b7d7887f770f5712b5f020afd260fcefcb4b09a0c707e1b2bc921c38d2944bf6045b6b9752295790806018d98cd95d43313f9079719bcb3c808ff9f6e6c2ad

data/.github/workflows/eslint-validation.yml

@@ -0,0 +1,46 @@
+name: ESLint Validation
+
+on:
+  pull_request:
+    paths:
+      - "eslint.config.js"
+      - "package.json"
+      - "package/**/*.js"
+      - "test/**/*.js"
+      - ".github/workflows/eslint-validation.yml"
+
+jobs:
+  validate:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Setup Node
+        uses: actions/setup-node@v4
+        with:
+          node-version: "20"
+          cache: "yarn"
+
+      - name: Install dependencies
+        run: yarn install --frozen-lockfile
+
+      - name: Validate ESLint config
+        run: |
+          echo "Validating ESLint configuration..."
+          node -e "const config = require('./eslint.config.js'); console.log('✓ Config is valid with', config.length, 'rule sets')"
+
+      - name: Run ESLint
+        run: |
+          echo "Running ESLint on allowed files..."
+          yarn eslint . --max-warnings 5
+
+      - name: Check warning count
+        run: |
+          echo "Checking warning count..."
+          WARNING_COUNT=$(yarn eslint . 2>&1 | grep -E "^✖.*warning" | grep -oE "[0-9]+ warning" | cut -d' ' -f1)
+          echo "Current warning count: $WARNING_COUNT"
+          if [ "$WARNING_COUNT" -gt "5" ]; then
+            echo "❌ Too many warnings: $WARNING_COUNT (max allowed: 5)"
+            exit 1
+          fi
+          echo "✓ Warning count is acceptable"

data/ESLINT_TECHNICAL_DEBT.md

@@ -0,0 +1,159 @@
+# ESLint Technical Debt Documentation
+
+This document tracks the ESLint errors currently suppressed in the codebase and outlines the plan to address them.
+
+## Current Approach
+
+**As of 2025-10-14**: All TypeScript files in `package/` directory are temporarily excluded from linting via the ignore pattern `package/**/*.ts` in `eslint.config.js`. This allows the project to adopt ESLint configuration without requiring immediate fixes to all existing issues.
+
+**Latest Update**: Fixed all `no-param-reassign` violations by refactoring to create new objects instead of mutating parameters (7 violations resolved).
+
+## Current Linting Status
+
+**Files currently linted** (`test/**/*.js`, `scripts/*.js`):
+
+- ✅ **0 errors** (CI passing)
+- ⚠️ **3 warnings** (acceptable, won't block CI)
+  - 1x unused eslint-disable directive in `scripts/remove-use-strict.js`
+  - 2x jest/no-disabled-tests in test files (expected for conditional test skipping)
+
+**TypeScript files** (currently ignored via `package/**/*.ts`):
+
+- **Estimated suppressed errors: ~163** (from sample analysis)
+  - TypeScript type-safety issues: ~114 (70%)
+  - Style/convention issues: ~49 (30%)
+
+**Target**: Reduce suppressed errors by 50% within Q1 2025
+**Last Updated**: 2025-10-15
+
+## Priority Matrix
+
+| Category                             | Impact | Effort | Priority | Count |
+| ------------------------------------ | ------ | ------ | -------- | ----- |
+| `@typescript-eslint/no-explicit-any` | High   | High   | P1       | 22    |
+| `@typescript-eslint/no-unsafe-*`     | High   | High   | P1       | 85    |
+| `config.ts` type safety              | High   | Medium | P1       | 7     |
+| `no-param-reassign`                  | Medium | Low    | P2       | 0     |
+| `class-methods-use-this`             | Low    | Low    | P3       | 0     |
+| `no-nested-ternary`                  | Low    | Low    | P3       | 0     |
+| `import/prefer-default-export`       | Low    | Medium | P3       | 9     |
+| `global-require`                     | Medium | High   | P2       | 3     |
+| Other style issues                   | Low    | Low    | P3       | 31    |
+
+## Categories of Suppressed Errors
+
+### 1. TypeScript Type Safety (Requires Major Refactoring)
+
+#### `@typescript-eslint/no-explicit-any` (22 instances)
+
+**Files affected:** `configExporter/`, `config.ts`, `utils/`
+**Why suppressed:** These require careful type definitions and potentially breaking API changes
+**Fix strategy:** Create proper type definitions for configuration objects and YAML parsing
+
+#### `@typescript-eslint/no-unsafe-*` (85 instances)
+
+- `no-unsafe-assignment`: 47 instances
+- `no-unsafe-member-access`: 20 instances
+- `no-unsafe-call`: 8 instances
+- `no-unsafe-return`: 8 instances
+- `no-unsafe-argument`: 7 instances
+  **Why suppressed:** These stem from `any` types and dynamic property access
+  **Fix strategy:** Requires comprehensive type refactoring alongside `no-explicit-any` fixes
+
+### 2. Module System (Potential Breaking Changes)
+
+#### `global-require` (3 instances)
+
+**Files affected:** `configExporter/cli.ts`
+**Why suppressed:** Dynamic require calls are needed for conditional module loading
+**Fix strategy:** Would require converting to ES modules with dynamic imports
+
+#### `import/prefer-default-export` (9 instances)
+
+**Files affected:** Multiple single-export modules
+**Why suppressed:** Adding default exports alongside named exports could break consumers
+**Fix strategy:** Can be fixed non-breaking by adding default exports that match named exports
+
+### 3. Code Style (Can Be Fixed)
+
+#### `class-methods-use-this` (0 instances)
+
+✅ **FIXED** - All FileWriter methods that didn't use instance state have been converted to static methods
+
+#### `no-nested-ternary` (0 instances)
+
+✅ **FIXED** - All nested ternary expressions have been refactored to if-else statements for better readability
+
+#### `no-param-reassign` (0 instances)
+
+✅ **FIXED** - Refactored `applyDefaults` function to return new objects instead of mutating parameters
+
+#### `no-underscore-dangle` (2 instances)
+
+**Fix strategy:** Rename variables or add exceptions for Node internals
+
+### 4. Control Flow
+
+#### `no-await-in-loop` (1 instance)
+
+**Fix strategy:** Use `Promise.all()` for parallel execution
+
+#### `no-continue` (1 instance)
+
+**Fix strategy:** Refactor loop logic
+
+## Recommended Approach
+
+### Phase 1: Non-Breaking Fixes
+
+✅ Completed:
+
+- Fixed `no-use-before-define` by reordering functions
+- Fixed redundant type constituents with `string & {}` pattern
+- Added proper type annotations for `requireOrError` calls
+- Configured appropriate global rule disables (`no-console`, `no-restricted-syntax`)
+- ✅ **Fixed `class-methods-use-this`** - Converted FileWriter methods to static methods
+- ✅ **Fixed `no-nested-ternary`** - Refactored to if-else statements for better readability
+- ✅ **Fixed `no-param-reassign`** - Refactored `applyDefaults` to return new objects instead of mutating parameters
+
+🔧 Could still fix (low risk):
+
+- `no-useless-escape` - Remove unnecessary escapes
+- Unused variables - Remove or prefix with underscore
+
+### Phase 2: Follow-up PRs (Non-Breaking)
+
+- Systematic type safety improvements file by file
+- Add explicit type definitions for configuration objects
+- Replace `any` with `unknown` where possible
+
+### Phase 3: Future Major Version (Breaking Changes)
+
+- Convert `export =` to `export default`
+- Convert `require()` to ES6 imports
+- Full TypeScript strict mode compliance
+- Provide codemod for automatic migration
+
+## Configuration Strategy
+
+The current approach uses file-specific overrides to suppress errors in affected files while maintaining strict checking elsewhere. This allows:
+
+1. New code to follow strict standards
+2. Gradual refactoring of existing code
+3. Clear visibility of technical debt
+
+## Issue Tracking
+
+GitHub issues should be created for each category:
+
+1. [ ] Issue: Type safety refactoring for configExporter module
+2. [ ] Issue: Type safety for dynamic config loading
+3. [ ] Issue: Convert class methods to static where appropriate
+4. [ ] Issue: Module system modernization (ES6 modules)
+5. [ ] Issue: Create codemod for breaking changes migration
+
+## Notes
+
+- All suppressed errors are documented in `eslint.config.js` with TODO comments
+- The suppressions are scoped to specific files to prevent spreading technical debt
+- New code should not add to these suppressions

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    shakapacker (9.3.0.beta.1)
+    shakapacker (9.3.0.beta.4)
       activesupport (>= 5.2)
       package_json
       rack-proxy (>= 0.6.1)

data/README.md

@@ -477,8 +477,8 @@ And the main layout has:
 is the same as using this in the main layout:
 
 ```erb
-<%= javascript_pack_tag 'calendar', 'map', application' %>
-<%= stylesheet_pack_tag 'calendar', 'map', application' %>
+<%= javascript_pack_tag 'calendar', 'map', 'application' %>
+<%= stylesheet_pack_tag 'calendar', 'map', 'application' %>
 ```
 
 However, you typically can't do that in the main layout, as the view and partial codes will depend on the route.
@@ -490,12 +490,13 @@ Thus, you can distribute the logic of what packs are needed for any route. All t
 The typical issue is that your layout might reference some partials that need to configure packs. A good way to solve this problem is to use `content_for` to ensure that the code to render your partial comes before the call to `javascript_pack_tag`.
 
 ```erb
-<% content_for :footer do
-   render 'shared/footer' %>
+<% content_for :footer do %>
+  <%= render 'shared/footer' %>
+<% end %>
 
 <%= javascript_pack_tag %>
 
-<%= content_for :footer %>
+<%= yield :footer %>
 ```
 
 There is also `prepend_javascript_pack_tag` that will put the entry at the front of the queue. This is handy when you want an entry in the main layout to go before the partial and main layout `append_javascript_pack_tag` entries.
@@ -522,11 +523,13 @@ And the main layout has:
 is the same as using this in the main layout:
 
 ```erb
-<%= javascript_pack_tag 'main', 'calendar', 'map', application' %>
+<%= javascript_pack_tag 'main', 'calendar', 'map', 'application' %>
 ```
 
 For alternative options for setting the additional packs, [see this discussion](https://github.com/shakacode/shakapacker/issues/39).
 
+**Important:** To prevent FOUC (Flash of Unstyled Content), always place `stylesheet_pack_tag` in the `<head>` section of your layout. When using `append_*` helpers with dynamic pack loading (e.g., React on Rails), use the `content_for` pattern to control execution order. See the [Preventing FOUC guide](./docs/preventing_fouc.md) for detailed examples.
+
 #### View Helper: `asset_pack_path`
 
 If you want to link a static asset for `<img />` tag, you can use the `asset_pack_path` helper:

data/docs/common-upgrades.md

@@ -6,6 +6,7 @@ This document provides step-by-step instructions for the most common upgrade sce
 
 ## Table of Contents
 
+- [Upgrading Shakapacker](#upgrading-shakapacker)
 - [Migrating Package Managers](#migrating-package-managers)
   - [Yarn to npm](#yarn-to-npm)
   - [npm to Yarn](#npm-to-yarn)
@@ -15,6 +16,85 @@ This document provides step-by-step instructions for the most common upgrade sce
 
 ---
 
+## Upgrading Shakapacker
+
+> **⚠️ Important:** Shakapacker is both a Ruby gem AND an npm package. **You must update BOTH** when upgrading.
+
+Shakapacker consists of two components that must be updated together:
+
+1. **Ruby gem** - provides Rails integration and view helpers
+2. **npm package** - provides webpack/rspack configuration and build tools
+
+### Upgrade Steps
+
+#### 1. Update `Gemfile`
+
+```ruby
+gem "shakapacker", "9.3.0"  # or the version you want to upgrade to
+```
+
+**Pre-release versions:** Ruby gems use dot notation (e.g., `"9.3.0.beta.1"`)
+
+#### 2. Update `package.json`
+
+```json
+{
+  "dependencies": {
+    "shakapacker": "9.3.0"
+  }
+}
+```
+
+**Pre-release versions:** npm uses hyphen notation (e.g., `"9.3.0-beta.1"`)
+
+#### 3. Run bundler and package manager
+
+```bash
+bundle update shakapacker
+yarn install  # or npm install, pnpm install, bun install
+```
+
+#### 4. Test your build
+
+```bash
+bin/shakapacker
+bin/shakapacker-dev-server
+```
+
+### Why Both Must Be Updated
+
+- **Mismatched versions can cause build failures** - The Ruby gem expects specific configuration formats from the npm package
+- **Feature compatibility** - New features in the gem require corresponding npm package updates
+- **Bug fixes** - Fixes often span both Ruby and JavaScript code
+
+### Version Format Differences
+
+Note that pre-release versions use different formats:
+
+| Component    | Stable Version | Pre-release Version |
+| ------------ | -------------- | ------------------- |
+| Gemfile      | `"9.3.0"`      | `"9.3.0.beta.1"`    |
+| package.json | `"9.3.0"`      | `"9.3.0-beta.1"`    |
+
+### Finding the Latest Version
+
+- **Ruby gem:** Check [RubyGems.org](https://rubygems.org/gems/shakapacker)
+- **npm package:** Check [npmjs.com](https://www.npmjs.com/package/shakapacker)
+- **Releases:** See [GitHub Releases](https://github.com/shakacode/shakapacker/releases)
+
+### Major Version Upgrades
+
+For major version upgrades, always consult the version-specific upgrade guides for breaking changes and new features:
+
+- [V9 Upgrade Guide](./v9_upgrade.md) - Upgrading from v8 to v9 (includes CSS Modules changes, SWC defaults, and more)
+- [V8 Upgrade Guide](./v8_upgrade.md) - Upgrading from v7 to v8
+- [V7 Upgrade Guide](./v7_upgrade.md) - Upgrading from v6 to v7
+- [V6 Upgrade Guide](./v6_upgrade.md) - Upgrading from v5 to v6
+
+> **💡 Note:** Major version upgrades may include breaking changes. The steps above cover the basic gem/package updates that apply to all versions, but you should always review the version-specific guide for additional migration steps.
+
+---
+
 ## Migrating Package Managers
 
 ### Yarn to npm

data/docs/configuration.md

@@ -12,6 +12,7 @@ This guide covers all configuration options available in `config/shakapacker.yml
 - [Compilation Options](#compilation-options)
 - [Advanced Options](#advanced-options)
 - [Environment-Specific Configuration](#environment-specific-configuration)
+- [Build Configurations (config/shakapacker-builds.yml)](#build-configurations-configshakapacker-buildsyml)
 
 ## Basic Configuration
 
@@ -608,6 +609,106 @@ default: &default
     - packages/ui-components
 ```
 
+## Build Configurations (config/shakapacker-builds.yml)
+
+Shakapacker supports defining reusable build configurations in `config/shakapacker-builds.yml`. This allows you to run predefined builds with a simple command, making it easy to switch between different build scenarios.
+
+### Creating a Build Configuration File
+
+Generate `config/shakapacker-builds.yml` with example builds:
+
+```bash
+bin/shakapacker --init  # Creates config/shakapacker-builds.yml
+```
+
+This generates a file with example builds for common scenarios (HMR development, standard development, and production).
+
+### Running Builds by Name
+
+Once you have `config/shakapacker-builds.yml`, you can run builds by name:
+
+```bash
+# List available builds
+bin/shakapacker --list-builds
+
+# Run a specific build
+bin/shakapacker --build dev-hmr    # Client bundle with HMR (automatically uses dev server)
+bin/shakapacker --build prod        # Client and server bundles for production
+bin/shakapacker --build dev         # Client bundle for development
+```
+
+### Build Configuration Format
+
+Example `config/shakapacker-builds.yml`:
+
+```yaml
+builds:
+  dev-hmr:
+    description: Client bundle with HMR (React Fast Refresh)
+    bundler: rspack # Optional: override assets_bundler from config/shakapacker.yml
+    environment:
+      NODE_ENV: development
+      RAILS_ENV: development
+      WEBPACK_SERVE: "true" # Automatically uses bin/shakapacker-dev-server
+    outputs:
+      - client
+    config: config/${BUNDLER}/custom.config.js # Optional: custom config file with variable substitution
+
+  prod:
+    description: Production client and server bundles
+    environment:
+      NODE_ENV: production
+      RAILS_ENV: production
+    outputs:
+      - client # Multiple outputs - builds both client and server bundles
+      - server
+```
+
+### Build Configuration Options
+
+- **`description`** (optional): Human-readable description of the build
+- **`bundler`** (optional): Override the default bundler from `config/shakapacker.yml` (`webpack` or `rspack`)
+- **`dev_server`** (optional): Boolean flag to force routing to dev server (overrides environment variable detection)
+- **`environment`**: Environment variables to set when running the build
+- **`outputs`**: Array of output types - can include `client`, `server`, or both for multiple bundles in a single build
+- **`config`** (optional): Custom config file path (supports `${BUNDLER}` variable substitution)
+- **`bundler_env`** (optional): Key-value pairs passed as bundler `--env` flags (e.g., `{ analyze: true }` becomes `--env analyze=true`)
+
+### Automatic Dev Server Detection
+
+Shakapacker automatically uses `bin/shakapacker-dev-server` instead of the regular build command when:
+
+1. The build has `dev_server: true` explicitly set (preferred method - takes precedence over environment variables), OR
+2. The build has `WEBPACK_SERVE=true` or `HMR=true` in its environment variables (fallback for backward compatibility)
+
+Example:
+
+```bash
+# These are equivalent:
+bin/shakapacker --build dev-hmr
+WEBPACK_SERVE=true bin/shakapacker-dev-server  # (with dev-hmr environment vars)
+```
+
+### Variable Substitution
+
+The `config` field supports `${BUNDLER}` substitution:
+
+```yaml
+builds:
+  custom:
+    bundler: rspack
+    config: config/${BUNDLER}/custom.config.js # Becomes: config/rspack/custom.config.js
+```
+
+### When to Use Build Configurations
+
+Build configurations are useful for:
+
+- **Multiple build scenarios**: Use when you need different builds for HMR development, standard development, and production
+- **CI/CD pipelines**: Use when you want predefined builds that can be referenced in deployment scripts
+- **Team consistency**: Use to ensure all developers use the same build configurations
+- **Complex setups**: Use to manage different bundler configs or environment variables for different scenarios
+
 ## Troubleshooting
 
 If you encounter configuration issues:

data/docs/preventing_fouc.md

@@ -0,0 +1,132 @@
+# Preventing FOUC (Flash of Unstyled Content)
+
+## Overview
+
+FOUC (Flash of Unstyled Content) occurs when content is rendered before stylesheets load, causing a brief flash of unstyled content. This guide explains how to prevent FOUC when using Shakapacker's view helpers.
+
+## Basic Solution
+
+Place `stylesheet_pack_tag` in the `<head>` section of your layout, not at the bottom of the `<body>`. This ensures styles load before content is rendered.
+
+**Recommended layout structure:**
+
+```erb
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <title>My App</title>
+
+  <%= stylesheet_pack_tag 'application', media: 'all' %>
+  <%= javascript_pack_tag 'application', defer: true %>
+</head>
+<body>
+  <%= yield %>
+</body>
+</html>
+```
+
+## Advanced: Using `content_for` with Dynamic Pack Loading
+
+If you're using libraries that dynamically append packs during rendering (like React on Rails with `auto_load_bundle`), or if you need to append packs from views/partials, you must ensure that all `append_*` helpers execute before the pack tags render.
+
+Rails' `content_for` pattern solves this execution order problem.
+
+### The `content_for :body_content` Pattern
+
+This pattern renders the body content first, allowing all append calls to register before the pack tags in the head are rendered:
+
+```erb
+<% content_for :body_content do %>
+  <%= render 'shared/header' %>
+  <%= yield %>
+  <%= render 'shared/footer' %>
+<% end %>
+
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <title>My App</title>
+
+  <%= stylesheet_pack_tag 'application', media: 'all' %>
+  <%= javascript_pack_tag 'application', defer: true %>
+</head>
+<body>
+  <%= yield :body_content %>
+</body>
+</html>
+```
+
+**How this works:**
+
+1. The `content_for :body_content` block executes first during template rendering
+2. Any `append_stylesheet_pack_tag` or `append_javascript_pack_tag` calls in your views/partials register their packs
+3. Libraries like React on Rails can auto-append component-specific packs during rendering
+4. The pack tags in `<head>` then render with all registered appends
+5. Finally, `yield :body_content` outputs the pre-rendered content
+
+**Result:**
+
+- ✅ All appends (explicit + auto) happen before pack tags
+- ✅ Stylesheets load in head, eliminating FOUC
+- ✅ Works with `auto_load_bundle` and similar features
+
+### Alternative: Using `yield :head` for Explicit Appends
+
+For simpler cases where you know which packs you need upfront and can explicitly specify them, you can use `content_for :head` in your views and yield it in your layout.
+
+**Layout (app/views/layouts/application.html.erb):**
+
+```erb
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <title>My App</title>
+
+  <%= yield :head %>
+  <%= stylesheet_pack_tag 'application', media: 'all' %>
+  <%= javascript_pack_tag 'application', defer: true %>
+</head>
+<body>
+  <%= yield %>
+</body>
+</html>
+```
+
+**View (app/views/pages/show.html.erb):**
+
+```erb
+<% content_for :head do %>
+  <%= append_stylesheet_pack_tag 'my-component' %>
+  <%= append_javascript_pack_tag 'my-component' %>
+<% end %>
+
+<h1>My Page</h1>
+<p>Content goes here...</p>
+```
+
+This approach works when:
+
+- You're not using auto-appending libraries
+- You can explicitly list all required packs in each view
+- You don't need dynamic pack determination
+
+## Key Takeaways
+
+- Always place `stylesheet_pack_tag` in `<head>` to prevent FOUC
+- Use `content_for` to control execution order when using `append_*` helpers
+- Ensure `append_*` helpers execute before the main pack tags
+- JavaScript can use `defer: true` (default) or be placed at end of `<body>`
+- The `content_for :body_content` pattern is essential when using auto-appending libraries
+
+## Related
+
+- [View Helpers Documentation](../README.md#view-helpers)
+- [Troubleshooting Guide](./troubleshooting.md)
+- Original issue: [#720](https://github.com/shakacode/shakapacker/issues/720)
+- Working implementation: [react-webpack-rails-tutorial PR #686](https://github.com/shakacode/react-webpack-rails-tutorial/pull/686)

data/docs/troubleshooting.md

@@ -1,5 +1,9 @@
 # Troubleshooting
 
+## Flash of Unstyled Content (FOUC)
+
+If you're experiencing FOUC where content briefly appears unstyled before CSS loads, see the [Preventing FOUC guide](./preventing_fouc.md) for solutions including proper `stylesheet_pack_tag` placement and `content_for` patterns for dynamic pack loading.
+
 ## Debugging your webpack config
 
 1. Read the error message carefully. The error message will tell you the precise key value