chore: prepare for migration

.github/workflows/daily-rebuild.yml

@@ -0,0 +1,24 @@
+name: Daily Vercel Redeploy
+
+on:
+  schedule:
+    - cron: '0 0 * * *'
+  workflow_dispatch:
+
+permissions: {}
+
+jobs:
+  redeploy:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Trigger Vercel redeploy
+        env:
+          VERCEL_REDEPLOY_HOOK: ${{ secrets.VERCEL_REDEPLOY_HOOK }}
+        run: |
+          curl \
+            --fail-with-body \
+            --silent \
+            --show-error \
+            --location \
+            "$VERCEL_REDEPLOY_HOOK"

README.md

@@ -1,4 +1,4 @@
-# webpack-doc-kit
+# webpack.js.org
 
 Automated TypeScript API documentation generator for [webpack](https://github.com/webpack/webpack). Extracts type definitions from webpack's `types.d.ts` and produces Markdown and HTML documentation, deployed to GitHub Pages.
 

components/Layout.jsx

@@ -1,4 +1,6 @@
 import DefaultLayout from '@node-core/doc-kit/src/generators/web/ui/components/Layout/index.jsx';
+import { Analytics } from '@vercel/analytics/react';
+import { SpeedInsights } from '@vercel/speed-insights/react';
 import HomeLayout from '../layouts/Home/index.jsx';
 import SponsorsLayout from '../layouts/Sponsors/index.jsx';
 import BlogLayout from '../layouts/Blog/index.jsx';
@@ -17,5 +19,11 @@ const LAYOUTS = {
 export default function Layout(props) {
   const Component = LAYOUTS[props.metadata.layout] ?? DefaultLayout;
 
-  return <Component {...props} />;
+  return (
+    <>
+      <Analytics />
+      <SpeedInsights />
+      <Component {...props} />
+    </>
+  );
 }

layouts/PageNotFound/index.jsx

@@ -21,7 +21,7 @@ export default ({ metadata }) => {
               Go to Home
             </BaseButton>
             <BaseButton
-              href="https://github.com/webpack/webpack-doc-kit/issues/new/choose"
+              href="https://github.com/webpack/webpack.js.org/issues/new/choose"
               kind="neutral"
             >
               Report an issue

package.json

@@ -1,4 +1,5 @@
 {
+  "name": "webpack.js.org",
   "scripts": {
     "build:prepare": "node scripts/prepare/index.mjs",
     "build:data": "npm-run-all build:data:*",
@@ -24,6 +25,8 @@
   "dependencies": {
     "@node-core/doc-kit": "1.4.3",
     "@tailwindcss/node": "^4.3.0",
+    "@vercel/analytics": "^2.0.1",
+    "@vercel/speed-insights": "^2.0.0",
     "classnames": "^2.5.1",
     "gray-matter": "^4.0.3",
     "npm-run-all": "^4.1.5",

pages/guides/contributing/debugging.md

@@ -0,0 +1,47 @@
+---
+title: Debugging
+authors: skipjack,tbroadley,madhavarshney,bhavya9107,akaustav
+---
+
+# Debugging
+
+When contributing to the core repo, writing a loader/plugin, or even working on a complex project, debugging tools can be central to your workflow. Whether the problem is slow performance on a large project or an unhelpful traceback, the following utilities can make figuring it out less painful.
+
+- The [`Stats` API](/docs/api/v5.x/stats/Stats) available through webpack's Node.js API and the [CLI](/docs/api/v5.x/cli).
+- Chrome **DevTools** and the latest Node.js version.
+
+## Stats
+
+Whether you inspect it manually or pass it to another tool, webpack's [`Stats` object](/docs/api/v5.x/stats/Stats) can be extremely useful when debugging build issues. It can provide the following information:
+
+- The contents of every module.
+- The modules contained within every chunk.
+- Per module compilation and resolving stats.
+- Build errors and warnings.
+- The relationships between modules.
+- And much more...
+
+On top of that, the official [analyze tool](https://github.com/webpack/analyse) and [various others](/guides/optimization/code-splitting/#bundle-analysis) will accept this data and visualize it in various ways.
+
+## DevTools
+
+While [`console`](https://nodejs.org/api/console.html) statements may work well in straightforward scenarios, sometimes a more robust solution is needed. As most front-end developers already know, Chrome DevTools are a life saver when debugging web applications, _but they don’t have to stop there_. As of Node v6.3.0+, developers can use the built-in `--inspect` flag to debug a node program in DevTools.
+
+Let's start by invoking webpack with the `node --inspect`.
+
+Note that we cannot run npm `scripts`, e.g. `npm run build`, so we'll have to specify the full `node_modules` path:
+
+```bash
+node --inspect ./node_modules/webpack/bin/webpack.js
+```
+
+Which should output something like:
+
+```bash
+Debugger listening on ws://127.0.0.1:9229/c624201a-250f-416e-a018-300bbec7be2c
+For help see https://nodejs.org/en/docs/inspector
+```
+
+Now jump to `chrome://inspect` in the browser and you should see any active scripts you've inspected under the _Remote Target_ header. Click the "inspect" link under each script to open a dedicated debugger or the _Open dedicated DevTools for Node_ link for a session that will connect automatically. You can also check out the [NiM extension](https://chrome.google.com/webstore/detail/nodejs-v8-inspector-manag/gnhhdgbaldcilmgcpfddgdbkhjohddkj), a handy Chrome plugin that will automatically open a DevTools tab every time you `--inspect` a script.
+
+We recommend using the `--inspect-brk` flag which will break on the first statement of the script allowing you to go through the source to set breakpoints and start/stop the build as you please. Also, don't forget that you can still pass arguments to the script. For example, if you have multiple configuration files you could pass `--config webpack.prod.js` to specify the configuration you'd like to debug.

pages/guides/contributing/plugin-patterns.md

@@ -0,0 +1,149 @@
+---
+title: Plugin Patterns
+authors: nveenjain,EugeneHlushko,benglynn,raj-sapalya
+---
+
+# Plugin Patterns
+
+Plugins grant unlimited opportunity to perform customizations within the webpack build system. This allows you to create custom asset types, perform unique build modifications, or even enhance the webpack runtime while using middleware. The following are some features of webpack that become useful while writing plugins.
+
+## Exploring assets, chunks, modules, and dependencies
+
+After a compilation is sealed, all structures within the compilation may be traversed.
+
+```js
+class MyPlugin {
+  apply(compiler) {
+    compiler.hooks.emit.tapAsync('MyPlugin', (compilation, callback) => {
+      // Explore each chunk (build output):
+      for (const chunk of compilation.chunks) {
+        // Explore each module within the chunk (built inputs):
+        for (const module of chunk.getModules()) {
+          // Explore each source file path that was included into the module:
+          if (module.buildInfo && module.buildInfo.fileDependencies) {
+            for (const fileDependency of module.buildInfo.fileDependencies) {
+              // we've learned a lot about the source structure now...
+              console.log(fileDependency);
+            }
+          }
+        }
+
+        // Explore each asset filename generated by the chunk:
+        for (const filename of chunk.files) {
+          // Get the asset source for each file generated by the chunk:
+          const source = compilation.assets[filename].source();
+        }
+      }
+
+      callback();
+    });
+  }
+}
+
+export default MyPlugin;
+```
+
+- `compilation.modules`: A set of modules (built inputs) in the compilation. Each module manages the build of a raw file from your source library.
+
+> [!WARNING]
+> **Deprecation warning**: Array functions will still work.
+
+- `module.fileDependencies`: An array of source file paths included into a module. This includes the source JavaScript file itself (ex: `index.js`), and all dependency asset files (stylesheets, images, etc) that it has required. Reviewing dependencies is useful for seeing what source files belong to a module.
+- `compilation.chunks`: A set of chunks (build outputs) in the compilation. Each chunk manages the composition of a final rendered assets.
+
+> [!WARNING]
+> **Deprecation warning**: Array functions will still work.
+
+- `chunk.getModules()`: An array of modules that are included into a chunk. By extension, you may look through each module's dependencies to see what raw source files fed into a chunk.
+- `chunk.files`: A Set of output filenames generated by the chunk. You may access these asset sources from the `compilation.assets` table.
+
+### Monitoring the watch graph
+
+While running webpack middleware, each compilation includes a `fileDependencies` `Set` (what files are being watched) and a `fileTimestamps` `Map` that maps watched file paths to a timestamp. These are extremely useful for detecting what files have changed within the compilation:
+
+```js
+class MyPlugin {
+  constructor() {
+    this.startTime = Date.now();
+    this.prevTimestamps = new Map();
+  }
+
+  apply(compiler) {
+    compiler.hooks.emit.tapAsync('MyPlugin', (compilation, callback) => {
+      const changedFiles = [...compilation.fileTimestamps.keys()].filter(
+        watchfile =>
+          (this.prevTimestamps.get(watchfile) || this.startTime) <
+          (compilation.fileTimestamps.get(watchfile) || Infinity)
+      );
+
+      this.prevTimestamps = compilation.fileTimestamps;
+      callback();
+    });
+  }
+}
+
+export default MyPlugin;
+```
+
+You may also feed new file paths into the watch graph to receive compilation triggers when those files change. Add valid file paths into the `compilation.fileDependencies` `Set` to add them to the watched files.
+
+> [!TIP]
+> The `fileDependencies` `Set` is rebuilt in each compilation, so your plugin must add its own watched dependencies into each compilation to keep them under watch.
+
+> [!WARNING]
+> Since webpack 5, `compilation.fileDependencies`, `compilation.contextDependencies` and `compilation.missingDependencies` are now a `Set` instead of a `Sortable Set` and thus no longer sorted.
+
+## Changed chunks
+
+Similar to the watch graph, you can monitor changed chunks within a compilation by tracking their content hashes.
+
+> [!WARNING]
+> `compilation.chunks` is a `Set`, not an array. Calling `.filter()` or `.map()` directly on it throws a `TypeError`.
+> Use `for...of` or spread it into an array first.
+
+> [!WARNING]
+> `chunk.hash` is not defined on chunk objects. Use `chunk.contentHash.javascript` instead.
+> Accessing `chunk.hash` returns `undefined`, causing every chunk to appear changed on every rebuild.
+
+```js
+class MyPlugin {
+  constructor() {
+    this.chunkVersions = {};
+  }
+
+  apply(compiler) {
+    compiler.hooks.emit.tapAsync('MyPlugin', (compilation, callback) => {
+      const changedChunks = [];
+
+      for (const chunk of compilation.chunks) {
+        const key = chunk.id ?? chunk.name;
+        const currentHash = chunk.contentHash.javascript;
+
+        if (currentHash === undefined) continue;
+
+        const oldHash = this.chunkVersions[key];
+        this.chunkVersions[key] = currentHash;
+
+        if (currentHash !== oldHash) {
+          changedChunks.push(chunk);
+        }
+      }
+
+      if (changedChunks.length > 0) {
+        console.log(
+          'Changed chunks:',
+          changedChunks.map(chunk => chunk.id)
+        );
+      }
+
+      callback();
+    });
+  }
+}
+
+export default MyPlugin;
+```
+
+> [!TIP]
+> Use `chunk.id ?? chunk.name` as the tracking key. Some chunks have an `id` but no `name`, so relying on `chunk.name` alone can miss changes.
+> CSS or other non-JS chunks may not have a `javascript` key in `contentHash` — the `continue` guard skips those safely.