webpack.js.org: the MDX repository behind the webpack documentation site

A documentation repository that webpack builds with webpack

webpack.js.org is the source repository behind https://webpack.js.org, the documentation site for the webpack bundler. Its one-line summary is a repository for webpack documentation and more, and its primary language is listed as MDX. Prose files are the working material here rather than compiled source.

The manifest names Greg Venech as author and carries four keywords: webpack, documentation, build, tool. Repository topics reach past core configuration into css, nodejs, web-performance, webpack-loader, webpack-plugin and webpack-tutorial, plus both webpack4 and webpack5, so the tree holds tutorials and plugin material as well as concept pages.

Site source sits under `src/`, and two runnable example directories sit beside it: `examples/getting-started/` and `examples/module-federation/`. Someone who only wants to watch webpack behave, without editing a single page, starts in those two folders. Which pages reach search engines is decided separately through `sitemap-ignore.json`, so the published URL surface is curated rather than whatever a build happens to emit. The last push landed on 2026-09-28.

Running the site locally starts webpack in development mode

Setup is split across two documents. Content writing goes to the writer's guide at https://webpack.js.org/contribute/writers-guide, and getting the site running locally goes to `.github/CONTRIBUTING.md`. Neither README section prints an install command, so the npm scripts in `package.json` are the real starting point.

The shortest path clears the output directory and starts the dev server:

npm run clean-dist && webpack serve --config webpack.dev.mjs --env dev --progress --config-node-env development

The cleanup step runs `rimraf ./dist`, so nothing stale survives from an earlier run. The dev config arrives with `--env dev` and a `development` node environment, which is what puts the bundler's own development behaviour in charge of the page you are editing.

Content changes need a second command, because navigation is generated rather than typed:

node src/scripts/build-content-tree.mjs ./src/content ./src/_content.json

That script reads `./src/content` and writes `./src/_content.json`. The naming pattern matters later, since the build deletes both kinds of file before it regenerates them. There is no library here to depend on.

Four config files split development, production and static output

The root carries `webpack.common.mjs`, `webpack.dev.mjs`, `webpack.prod.mjs` and `webpack.ssg.mjs`, so one repository holds four webpack configurations rather than a single file full of environment branches. Development goes through webpack serve with `webpack.dev.mjs`. Production output comes from `webpack.prod.mjs` under a `production` node environment. A fourth pass through `webpack.ssg.mjs` runs with `--env ssg`, one more stage in the build.

That last pass is worth reading closely:

webpack --config webpack.ssg.mjs --config-node-env production --env ssg --profile --json > stats.json

`--json` redirects webpack's statistics into `stats.json` instead of the terminal, and the same file is what the bundle analysis script feeds to `webpack-bundle-analyzer`. A site that documents webpack and profiles itself with webpack means a regression in the bundler surfaces first in the documentation build, where maintainers already watch it.

Generated content is deleted before every build

`prebuild` runs `npm run clean`, and that clean step is destructive by design. It removes `src/content/**/_*.mdx`, `src/**/_*.json` and `repositories/*.json`. A separate `preclean` step chains `clean-dist` and `clean-printable`, and `clean-printable` strips `src/content/**/printable.mdx`.

Files matching `src/content/**/_*.mdx` or `src/**/_*.json` are therefore never edited by hand. They come out of `src/content` through the tree script, then get read by the site. That keeps navigation in step with the prose, and it also means a fresh checkout cannot produce a site until the generators have run.

If a page is missing from a sidebar, look first at the file that clean deleted. The root does carry a `.gitignore`, but the repository listing does not show which of these generated paths it covers, so do not assume those files are tracked in git. The practical rule for contributors is simple: leave anything matching those two globs alone, because the next build removes it.

Every build fetches readmes, supporters and governance data

Content that belongs to other repositories is pulled in during the build rather than vendored into this one. Four scripts do the fetching, declared under a colon-prefixed namespace:

"fetch": "run-p fetch:*",
"fetch:readmes": "node src/utilities/fetch-package-readmes.mjs",
"fetch:governance": "node src/utilities/fetch-governance.mjs"

`fetch` expands the glob with `run-p`, which runs `fetch:readmes`, `fetch:supporters` and `fetch:governance` in parallel. A separate `fetch-repos` script calls `src/utilities/fetch-package-repos.mjs`, and `fetch-all` chains that script in front of the parallel group so nothing is missed. The build opens with `run-s fetch-repos fetch content`, so every single build depends on those network calls, and no offline fallback exists in the scripts. On a machine that cannot reach the network, the pipeline stops before webpack is ever invoked, which is why a cloned repository on its own is not a working site.

Vale, cspell, husky and Cypress sit in the same root

Content tooling and application tooling share one root here. Prose checking is configured through `.vale.ini` and a `.vale/` directory, spelling through `cspell.json`, and markdown style through `.markdownlint.json` with a matching `.markdownlintignore`. Formatting belongs to `prettier.config.mjs` and `.prettierignore`, linting to `eslint.config.mjs`, transpilation to `.babelrc` against targets in `.browserslistrc`.

Tests come in two flavours: `jest.config.mjs` for units and `cypress.config.js` with a `cypress/` directory for browser runs, with a `browserstack-logo.png` at the root beside them. Git hooks live in `.husky/`.

The header badges are easy to misread. Three sit in a row: a build status badge, a Standard Version badge, and a GitHub Discussions badge whose target is the bundler's repository rather than the documentation repository, so discussion happens next to the code. The only workflow named in that badge is Deploy, and the README does not say which of the checks above gate a pull request, so anyone unsure should assume the lint configuration has to pass.

Older documentation moved to its own subdomain and repository

Since webpack 4, versioned documentation lives on subdomains rather than inside one switchable tree. The webpack 4 documentation is served at `https://v4.webpack.js.org/` and is deployed from the `gh-pages` branch of a separate v4.webpack.js.org repository, so the older corpus has its own build and its own deploy target rather than sharing the `main` branch. Translations follow the same shape and sit on a dedicated `translation` branch.

Here is what a skim misses. The three newest tags attached to this repository are webpack 4 versions: v4.41.2 dated 2019-11-18, v4.30.0 dated 2019-04-19 and v4.28.2 dated 2019-01-22, even though the topics list webpack5 alongside webpack4 and the site is built from `main` on every Deploy run. Those tags track the bundler rather than the documentation, and the Standard Version badge in the header names the tool that normally derives such names from commit messages. Nobody should read the newest tag as a version of this site. The README also records that various known issues remain on the older archive, tracked as issue 3366.

The frozen archive and the live site solve the same problem differently

Put this repository next to the webpack 4 archive and the design difference is plain. The live site is a moving target: it deletes generated navigation, rebuilds a content tree, and fetches readmes, supporters and governance data from other repositories on every build, so pages change when upstream changes. The webpack 4 archive is frozen by comparison. Its content is deployed from the `gh-pages` branch of its own repository, and no fetch step is wired into it, so it keeps serving the text it was built with and never picks up a change on its own. One model keeps a single site current at the cost of requiring network access at build time; the other guarantees a stable URL at the cost of going stale.

There is also a boundary worth stating. The prose is available under CC BY 4.0, so text can be reused with attribution, while the build system itself stays private to this repository. And there is no API reference directory at the root: if you want a copy of webpack's type signatures or runtime exports, this tree does not carry one.

Editorial conclusion

This repository is the right starting point if you want to change webpack's own documentation, translate it, or run the site on your own machine, because the four webpack configs, the content tree script and the lint setup all sit in the open. It is not a package: `private` is true, `main` is `n/a` and the version field reads 0.1.2, so nothing here installs or imports. Confirm first that your machine can reach the four fetch scripts, since every build pulls readmes, supporters and governance data from other repositories before webpack runs.

Frequently asked questions

Official sources

1. License: CC-BY-4.0
2. Project website
3. README
4. Releases
5. webpack/webpack.js.org on GitHub