AVOID — Stale and unlicensed — last commit 5y ago

• 23+ active contributors
• ⚠ Stale — last commit 5y ago
• ⚠ Concentrated ownership — top contributor handles 61% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ No test directory detected
• ⚠ Scorecard: marked unmaintained (0/10)
• ⚠ Scorecard: default branch unprotected (0/10)

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests + OpenSSF Scorecard}

A collection of 15 progressively-complex Webpack configuration examples (demo01 through demo15) that teach the core bundler from entry points through advanced patterns like code-splitting, CSS modules, and React Router. Each demo is a self-contained, runnable Node.js project with its own webpack.config.js, source files, and npm scripts—designed for learning Webpack's key capabilities without boilerplate noise. Flat structure: 15 sibling directories (demo01/ through demo15/), each a complete mini-project with its own package.json, webpack.config.js, and source files (main.js, main.jsx, app.css, images). No shared /src or /lib—each demo is intentionally isolated to teach one concept in isolation (e.g., demo03 focuses only on Babel loader, demo04 only on CSS loading).

JavaScript developers and frontend engineers new to Webpack (especially those coming from browserify or raw script tags) who want to understand module bundling, asset loading, and build optimization through minimal, copy-paste-able examples rather than large framework scaffolding.

This is an educational reference repository, not a production library. It has accumulated 15 stable demo folders over several years but shows signs of age: Webpack 1.x/2.x era configuration patterns (no webpack.config.js with mode property visible), no test suite, and likely hasn't been updated for modern Webpack 5+ defaults. Suitable as a learning tool and historical reference, not as a template for new projects.

Low risk for its intended use (learning/reference), but the configurations are outdated: they use deprecated Webpack loaders and plugins (e.g., extract-text-webpack-plugin pattern, no dev/prod splitting via 'mode'). Single maintainer (ruanyf) with infrequent commits. No CI/CD setup visible. Not suitable as a bootstrap for production applications—use create-react-app, Next.js, or Vite instead.

No active development visible from the file list. This is a static reference corpus. New Webpack versions (5.x+) and ecosystem tools (create-react-app, Vite, esbuild) have superseded hands-on learning from raw configs. The repo serves as historical documentation of Webpack 1.x/2.x patterns.

Check README for instructions.

Daily commands: Per-demo, e.g. cd demo01 && npm run dev (starts webpack-dev-server). For production: npm run build (runs webpack -p, minifies and optimizes). Global install required: npm i -g webpack webpack-dev-server (as per README).

• README.md — Entry point documentation explaining webpack concepts, installation steps, and demo navigation—essential for understanding the repo's pedagogical purpose
• demo01/webpack.config.js — First configuration example establishing the baseline webpack setup pattern used across all subsequent demos
• demo01/main.js — Simplest entry point demonstrating webpack's module bundling foundation before adding complexity
• demo02/webpack.config.js — Introduces multiple entry points and outputs—critical pattern for understanding webpack's multi-bundle capabilities
• demo03/webpack.config.js — First JSX/loader example showing how webpack extends beyond vanilla JavaScript via loaders
• demo13/webpack.config.js — Demonstrates vendor bundle extraction and CommonsChunkPlugin—advanced optimization technique essential for production builds
• package.json — Root configuration with npm scripts (dev/build) and webpack tooling dependencies required for all demos

• Entry Point (e.g., main.js) (JavaScript/JSX, CommonJS require() or ES6 import) — Root module that webpack begins bundling from; imports other modules and assets, defines application bootstrap logic
  • Failure mode: Missing entry file or syntax errors prevent webpack from starting compilation
• Loader (babel-loader, css-loader, url-loader) (Webpack loader API, corresponding transpiler/processor) — Transforms non-JS files or JS dialects into format webpack understands; executed during compilation phase
  • Failure mode: Misconfigured test regex or missing loader package causes file type to fail bundling
• webpack.config.js (CommonJS module, Node.js) — Configuration object defining entry points, output paths, loaders, plugins, and optimization settings
  • Failure mode: Invalid config syntax or typos cause webpack CLI to fail before compilation begins
• webpack-dev-server (Express.js-based dev server, WebSocket for HMR communication) — HTTP server serving bundles with file watching and HMR; enables rapid development iteration
  • Failure mode: Port conflicts, file watcher limits, or misconfigured publicPath break dev workflow
• Bundle Output (bundle.js, chunks) — Generated static files containing all application code and assets, ready for

Add a New Demo with Custom Loader

1. Create new demo directory (e.g., demo16/) with package.json, webpack.config.js, main.js, and index.html following demo01 structure (demo01/package.json)
2. Define loader configuration in webpack.config.js module.rules to handle new file type (reference demo04 for CSS or demo05 for images) (demo04/webpack.config.js)
3. Create entry point (main.js) importing the new asset type and requiring it in bundle (demo01/main.js)
4. Create sample asset file matching the loader's expected input format (demo04/app.css)

Implement Code Splitting for Lazy Loading

1. Reference demo10/webpack.config.js to configure output.chunkFilename and ensure webpack version supports require.ensure or dynamic import (demo10/webpack.config.js)
2. In entry file (e.g., demo10/main.js), use require.ensure() to wrap module imports that should load asynchronously (demo10/main.js)
3. Create separate module file (demo10/a.js pattern) containing code to be split into chunk (demo10/a.js)
4. Build and verify output includes both bundle.js and 0.bundle.js (chunk file) in output directory (demo10/bundle.js)

Extract Vendor Code to Separate Bundle

1. Add CommonsChunkPlugin to webpack.config.js plugins array (see demo13/webpack.config.js for syntax) (demo13/webpack.config.js)
2. Ensure entry point and vendor.js both require() the shared dependencies (demo13/vendor.js)
3. Configure plugin with name:'vendor' to extract commons into separate output file (demo13/webpack.config.js)
4. Load both vendor bundle and main bundle in index.html in correct order (vendor first) (demo13/index.html)

• Webpack — Module bundler that transforms ES6/CommonJS modules and non-JS assets into static bundles optimized for browser consumption; enables code splitting and lazy loading
• webpack-dev-server — Development HTTP server with hot module replacement (HMR) enabling fast iteration by avoiding full page reloads during development
• Babel (implicit via loaders) — JSX and ES6+ transpilation to ES5 for browser compatibility, evident from demo03+ using .jsx files with loaders
• CSS/Style loaders — Enables importing CSS as modules and injecting into DOM dynamically; seen in demo04+ configurations

• Educational demos prioritize clarity over production best-practices

  • Why: Repo is explicitly a learning tool; each demo isolates one webpack concept to minimize cognitive load
  • Consequence: Configs lack optimizations like aggressive minification, hashing, or advanced caching strategies only shown in later demos

• Multiple independent demo directories vs. single monorepo

  • Why: Allows learners to cd into each demo and experiment in isolation without affecting others
  • Consequence: Code duplication across webpack.config.js files; no shared abstraction layer or base config

• Incremental feature introduction (demo01 → demo15)

  • Why: Pedagogical sequencing ensures prerequisites are met before advanced concepts like code splitting or vendor extraction
  • Consequence: Later demos depend on reader understanding earlier patterns; non-linear learning paths require backtracking

• Does not provide production-grade optimization (no tree-shaking, scope hoisting, or aggressive code minification demonstrated)
• Does not cover webpack 5 or module federation (repo appears to target webpack 1.x–3.x era)
• Does not include end-to-end testing or linting integration
• Does not handle authentication, API integration, or state management—focused solely on bundling and asset transformation

1. Global install of webpack and webpack-dev-server required (npm i -g webpack webpack-dev-server); just npm install in the project won't work. 2. Old Node/npm versions may fail silently with these Webpack 1.x configs; expect issues on Node 18+. 3. Loaders order matters (demo04: style-loader BEFORE css-loader) but the configs don't always comment why. 4. Each demo has its own node_modules; running npm install in the root installs nothing useful—you must cd into each demo. 5. webpack-dev-server --open flag assumes a browser exists on the system; headless CI will fail silently.

• Entry and Output — Webpack's core I/O model: entry tells it where to start reading the module graph, output tells it where to write the bundle. Understanding this is prerequisite for all other Webpack concepts.
• Loaders — Webpack only natively understands JavaScript; loaders are transformation pipelines (babel-loader, css-loader, file-loader) that turn non-JS assets into JS modules. Critical to bundling CSS, images, JSX.
• Plugins — Unlike loaders (file-level transforms), plugins hook into Webpack's lifecycle (compile, emit, done) to perform global optimizations like minification, HTML generation, and environment variable injection.
• Code Splitting — Splitting a single bundle into multiple files (via require.ensure or entry points) reduces initial page load time by deferring non-critical code; demo10-13 show this pattern essential for large apps.
• CSS Modules — Scoped CSS via local class names (demo06) prevents global stylesheet collisions in large projects; a pattern that Webpack enables but is not unique to it.
• Hot Module Replacement (HMR) — webpack-dev-server's --devtool eval enables instant code reload without full page refresh; foundational to modern dev workflows, though not explicitly configured in these demos.
• Minification and Source Maps — UglifyJS plugin (demo07) and -d flag shrink and debug bundles; demo07 shows the plugin pattern for production optimization, -d shows the -d command for embedded source maps.

• webpack/webpack — The official Webpack repository; these demos are teaching material for the core project itself.
• facebook/create-react-app — Modern successor for React projects: abstracts away Webpack config entirely, making these demos less necessary for new projects but useful for understanding what CRA hides.
• vitejs/vite — Alternative bundler with faster dev server; represents the next generation beyond Webpack's config-heavy approach that these demos teach.
• webpack-contrib/awesome-webpack — Curated list of Webpack loaders, plugins, and tools; extends the isolated examples here with ecosystem context and plugin discovery.
• baileys/webpack-chain — Fluent API for building Webpack configs programmatically; useful for learners moving from these imperative demos to more maintainable config generation.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add demo12 implementation and documentation for advanced webpack features

demo12 directory exists but is empty in the file structure. This is a clear gap in the demo sequence. A new contributor could implement demo12 to cover an important webpack feature not yet demonstrated (such as webpack optimization plugins, tree-shaking configuration, or CommonChunkPlugin usage), add webpack.config.js, package.json, and supporting source files, then document it in the README's demo list.

• [ ] Create demo12/webpack.config.js with a specific advanced feature (e.g., optimization or plugin configuration)
• [ ] Create demo12/package.json with appropriate dependencies
• [ ] Create demo12/main.js and demo12/index.html to demonstrate the feature
• [ ] Add a brief section in README.md describing what demo12 teaches about webpack

Add a scripts/test-demos.sh script to verify all demos build and run correctly

Currently there is no automated way to validate that each demo (demo01 through demo11) can successfully build and run. This is critical for maintenance as webpack versions change. A contributor could create a shell script or Node.js script that iterates through each demo directory, runs npm install, npm run build, and validates output files (bundle.js, 0.bundle.js, etc.) exist with correct content.

• [ ] Create scripts/test-demos.sh that iterates through demo01-demo11 directories
• [ ] For each demo, run 'npm install' and 'npm run build' to ensure webpack compilation succeeds
• [ ] Validate that expected output files (bundle.js, 0.bundle.js where applicable) are generated
• [ ] Add test script reference to root package.json under scripts section

Add .gitignore entries for demo-specific build artifacts and create per-demo package.json improvements

Currently .gitignore exists but likely doesn't account for all the node_modules and build artifacts generated by running demos individually. Additionally, each demo's package.json lacks explicit webpack and webpack-dev-server versions, making them fragile across different environments. A contributor could audit and update all demo*/package.json files to specify webpack and webpack-dev-server versions matching the README's installation instructions, and enhance .gitignore with patterns for demo-specific artifacts.

• [ ] Review and enhance .gitignore to include node_modules/ patterns, demo*/node_modules/, and any untracked bundle files
• [ ] Update all demo01 through demo11 package.json files to include explicit 'devDependencies' with pinned webpack and webpack-dev-server versions
• [ ] Test that running 'npm install && npm run build' in each demo produces consistent, reproducible builds
• [ ] Document the minimum webpack version requirements in README.md

• Add demo16/ teaching Webpack's resolve aliases (for 'import from @utils' syntax): copy demo01/, add resolve: { alias: { '@utils': path.resolve(__dirname, 'utils/') } } to webpack.config.js, create a utils/ folder, and document it in README.md.
• Add missing package.json fields (author, repository, description) to all 15 demos: bulk edit or script to fill in boilerplate metadata for consistency and npm search discoverability.
• Create a test-all.sh script that cds into each demo01-demo15 and runs npm run build to verify all configs still parse; currently no verification that old configs work with modern Node versions.

This is an educational demo repository with moderate security concerns, primarily related to outdated dependencies and insecure default configurations. The main risks are: (1) likely vulnerable versions of webpack/webpack-dev-server due to age, (2) potential exposure of dev server to untrusted networks, (3) lack of security headers, and (4) missing dependency lock file. As a learning resource, it serves its purpose but should not be used as a template for production applications without significant security hardening. Users should pin dependencies to secure versions, restrict dev server access, and implement proper security headers.

• High · Outdated Webpack and Build Tools — package.json - dependencies section. The package.json references webpack and webpack-dev-server without version pinning. Given this is a demo repository (likely created years ago based on the webpack v1 era naming), these dependencies are almost certainly outdated and contain known security vulnerabilities. No lock file (package-lock.json or yarn.lock) is mentioned in the file structure. Fix: Pin specific versions of webpack and webpack-dev-server to secure versions. Use npm audit to identify vulnerabilities. Consider using npm ci with a lock file instead of npm install. Update to modern webpack versions (v4+).
• High · Dev Server Exposure — README.md - usage instructions, webpack.config.js files. The README instructs users to run webpack-dev-server with default settings (listening on 0.0.0.0:8080 by default in older versions). The dev server is not production-hardened and should never be exposed to untrusted networks. There is no documentation about restricting access. Fix: Explicitly configure webpack-dev-server to listen only on localhost (127.0.0.1) in development. Never expose dev servers to public networks. Add security headers and HTTPS for any development server accessible beyond localhost.
• Medium · Missing Security Headers Configuration — demo*/index.html files, webpack.config.js files. The webpack configurations do not show any security-related headers (Content-Security-Policy, X-Frame-Options, etc.). The index.html files lack security directives that would protect against XSS and clickjacking attacks. Fix: Add security headers via webpack-dev-server devServer.headers configuration or HTTP headers middleware. Implement Content-Security-Policy headers and other defensive headers in all HTML files.
• Medium · No Dependency Integrity Verification — Repository root - missing package-lock.json or yarn.lock. No npm lock file is visible in the repository structure. This means installations cannot be reproduced consistently, and malicious package versions could be installed via dependency confusion attacks. Fix: Generate and commit package-lock.json (npm) or yarn.lock (yarn) to ensure reproducible installs. Use 'npm ci' instead of 'npm install' in CI/CD pipelines.
• Low · Bundle Analysis Tools Missing — webpack.config.js files across demos. There are no bundle size analysis tools configured. This can lead to accidental inclusion of large vulnerable dependencies or sensitive data in bundles. Fix: Add webpack-bundle-analyzer or similar tools to monitor bundle contents. Add bundle size limits to build configuration to catch unexpected inclusions.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/ruanyf/webpack-demos shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live ruanyf/webpack-demos repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ruanyf/webpack-demos.

What it runs against: a local clone of ruanyf/webpack-demos — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in ruanyf/webpack-demos | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 2014 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of ruanyf/webpack-demos. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/ruanyf/webpack-demos.git
#   cd webpack-demos
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of ruanyf/webpack-demos and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ruanyf/webpack-demos(\\.git)?\\b" \\
  && ok "origin remote is ruanyf/webpack-demos" \\
  || miss "origin remote is not ruanyf/webpack-demos (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "demo01/webpack.config.js" \\
  && ok "demo01/webpack.config.js" \\
  || miss "missing critical file: demo01/webpack.config.js"
test -f "demo01/main.js" \\
  && ok "demo01/main.js" \\
  || miss "missing critical file: demo01/main.js"
test -f "demo02/webpack.config.js" \\
  && ok "demo02/webpack.config.js" \\
  || miss "missing critical file: demo02/webpack.config.js"
test -f "demo03/webpack.config.js" \\
  && ok "demo03/webpack.config.js" \\
  || miss "missing critical file: demo03/webpack.config.js"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 2014 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1984d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/ruanyf/webpack-demos"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.