웹팩 포함 GSoC 2026 | 3 ~ 6주차 – 많은 일 발생

Hey, ryzrr back 🙌. a lot shipped since the last post so let’s get into it.

what i shipped

• feat: add governance docs fetcher under pages/contribute/governance #127

  Summary Adds a script scripts/markdown/governance.mjs that fetches the webpack governance repository’s markdown files.

  What kind of change does this PR introduce? Automated governance docs fetching.

  Did you add tests for your changes? No

  Does this PR introduce a breaking change? No

  If relevant, what needs to be documented once your changes are merged or what have you already documented? None

  Use of AI For Regex logic and lookaheads

  – governance docs fetcher, pulls webpack governance docs at build time and renders them under /about/governance

• ci: run site build on PRs #146

  Summary

  Adds the CI Build to run on every PR.

  What kind of change does this PR introduce? CI Addition

  Did you add tests for your changes? Not Needed.

  Does this PR introduce a breaking change? No

  If relevant, what needs to be documented once your changes are merged or what have you already documented?

  None Use of AI

  No

  – CI now builds the site on every PR and uploads the artifact for downloadble version.

• feat(banner): show latest webpack release instead of Node.js banner #151

  Fixes : #143 Summary Bugfix + feature :- fixes the Node.js banner leaking in and shows a webpack release banner instead.

  What kind of change does this PR introduce? Feat

  Did you add tests for your changes? No

  Does this PR introduce a breaking change? no

  If relevant, what needs to be documented once your changes are merged or what have you already documented? NA

  Use of AI for regex

  – release banner, auto-script approach got dropped in favour of a hand-edited self-documenting JSON config

• ci: add CodeQL scanning #155

  Summary Adds a CodeQL security-scanning

  What kind of change does this PR introduce? CI/tooling

  Did you add tests for your changes? No

  Does this PR introduce a breaking change? No

  If relevant, what needs to be documented once your changes are merged or what have you already documented? NA

  Use of AI No

  / #157 – CodeQL and zizmor scanning, both merged clean

• fix : version picker to the API docs and highlight the overview as active #160

  Summary Adds the version picker and the fixup to make overview in the governance section as active (highlighted)

  What kind of change does this PR introduce? Fixes some Bug and one improvement

  Did you add tests for your changes? NO

  Does this PR introduce a breaking change? NO

  If relevant, what needs to be documented once your changes are merged or what have you already documented? NA

  Use of AI for the regex and testing

  – version picker on API docs + sidebar active-state fix

• feat(docs): add loaders and plugins index pages #153

  This adds the loaders and plugins index pages, so /docs/loaders and /docs/plugins finally point to real landing pages instead of dead links (the footer already linked to them). I copied the content over from webpack.js.org and fixed up the links: our own loaders/plugins point to their local pages, built-in plugins point to their API docs, and the third-party ones keep their npm/GitHub links.

  This also unblocks the #TODO[/loaders] and #TODO[/plugins] markers in the guides from #147, since they now have somewhere to go.

  – loaders and plugins index landing pages

• fix(docs): resolve the guide TODOs for the plugin to its API references #163

  Issue – #158

  Summary Fixes some of the TODOs links

  What kind of change does this PR introduce? Fixing the Todos

  Did you add tests for your changes? No

  Does this PR introduce a breaking change? No

  If relevant, what needs to be documented once your changes are merged or what have you already documented? NA

  Use of AI Yes.

  – resolved guide TODO placeholder links to plugin API references

what I actually learned

one table should drive everything
Thanks to my mentor for this clear direction,
for the governance fetcher, i built a single FILE_MAP that drives output slugs, sidebar labels, link rewrites, and output order. adding a new governance doc is a one-line change:

const FILE_MAP = {
  'README.md': { output: 'index', label: 'Overview' },
  'CHARTER.md': { output: 'charter', label: 'Charter' },
};

const pageLink = output =>
  output === 'index' ? '/about/governance' : `/about/governance/${output}`;

Enter fullscreen mode Exit fullscreen mode

instead of scattering config across multiple files, one source of truth means one place to change. took me a bit to land on this but it made everything downstream cleaner.

automation vs manual control is a real design work

my first cut of the release banner was fully automated, script pulls the latest release and generates the banner. clean in theory. but there are real situations where a maintainer needs the banner to say something specific and automation just gets in the way.

so we decided going up with a self-documenting JSON config instead:

{
  "//": [
    "To put a banner up, copy 'example' into 'index' and edit the text.",
    "type is 'default' (blue), 'warning' (orange), or 'error' (red)."
  ],
  "websiteBanners": {
    "example": {
      "text": "webpack 5.x.0 is now available, read the release notes",
      "link": "/blog/posts/your-release-post",
      "type": "default"
    }
  }
}

Enter fullscreen mode Exit fullscreen mode

no entry, no banner. dead simple, no magic.

always check if something already has what you need

my first approach for detecting the current version in the version picker was this:

const currentVersion = isVersioned
  ? JSON.stringify(sidebar).match(/\/docs\/api\/v\d+\.x/)?.[0]
  : undefined;

Enter fullscreen mode Exit fullscreen mode

pattern-matching against the sidebar JSON to extract the version. it worked,
but i completely forgot the config already exposes it directly. the fix was simple:

import { version } from '#theme/config';

const versionBase = isVersioned ? `/docs/api/v${version.major}.x` : '';

Enter fullscreen mode Exit fullscreen mode

one import, done. lesson: before doing something clever, check if the boring solution already exists somewhere in the codebase.

read review comments before pushing a fix

i pushed a fixup on PR before reading the comments properly and fixed the thing. caught it myself, but coincidently it was correct. not a disaster but the kind of thing you don’t forget.

what’s next

wrapping up loose ends mostly. identifying anything missing, catching edge cases, and generally making sure things hold up before we call it production-ready. CI hardening, filling automation gaps, and tackling the version routing things.

will be back, ryzrr!