DEV Community: Nikhil Kumar Rajak

GSoC 2026 with webpack | weeks 3 to 6 - a lot happened

Nikhil Kumar Rajak — Sun, 05 Jul 2026 13:34:45 +0000

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

ryzrr posted on Jun 09, 2026

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

View on GitHub

- governance docs fetcher, pulls webpack governance docs at build time and renders them under /about/governance
ci: run site build on PRs #146

ryzrr posted on Jun 18, 2026

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

View on GitHub

- 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

ryzrr posted on Jun 20, 2026

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

View on GitHub

- release banner, auto-script approach got dropped in favour of a hand-edited self-documenting JSON config
ci: add CodeQL scanning #155

ryzrr posted on Jun 22, 2026

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

View on GitHub

/ #157 - CodeQL and zizmor scanning, both merged clean
fix : version picker to the API docs and highlight the overview as active #160

ryzrr posted on Jun 29, 2026

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

View on GitHub

- version picker on API docs + sidebar active-state fix
feat(docs): add loaders and plugins index pages #153

ryzrr posted on Jun 21, 2026

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.

View on GitHub

- loaders and plugins index landing pages
fix(docs): resolve the guide TODOs for the plugin to its API references #163

ryzrr posted on Jul 03, 2026

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.

View on GitHub

- 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}`;

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"
    }
  }
}

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;

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` : '';

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!

First post of my GSoC'26 journey at webpack, more to come 🚀

Nikhil Kumar Rajak — Sat, 20 Jun 2026 08:19:11 +0000

Nikhil Kumar Rajak

Jun 20

GSoC 2026 with webpack | working on webpack-doc-kit

#webdev #opensource #webpack #gsoc

2 min read

GSoC 2026 with webpack | working on webpack-doc-kit

Nikhil Kumar Rajak — Sat, 20 Jun 2026 08:15:53 +0000

Hola, i'm ryzrr, working on webpack-doc-kit as part of GSoC 2026 with the webpack org. first post here, I know I'm a bit late 🥲 gonna keep it focused on what i actually did instead of writing a whole essay about my feelings on open source, will definitely write but in the next blog post :)

my part of the project is CI/CD ,deployment automation and release awareness for the pipeline. sounds interesting ,right ? but let me tell you it's the stuff that quietly breaks everything if you get it wrong, so i'll take it.

community bonding

mostly just read stuff. issues, existing pipeline code, how versioning worked before i touched anything. also figured out how my work overlaps with my team mates so we don't end up building the same thing twice by accident & followed by a daily conversation on Discord and discussions and a onboarding meet.

barely wrote any code this phase. felt weird at first not to be shipping anything but turns out understanding the thing you're about to automate is kind of important. who knew.

what i actually shipped

versions.json - the file that tracks the latest version of the webpack release across the whole doc pipeline. had to exist before anything downstream could rely on it, so this was step one.

feat: add versions.json version metadata contract #110

ryzrr posted on May 26, 2026

Links to : #105

Summary

Adds versions.json as the shared version metadata contract for the documentation pipeline. This is the single source of truth that update-versions.mjs, place-output.mjs, release.yml will all read from.

Real values: v5.x reflects the actual latest webpack release on npm (5.107.1) and the commit matches the current HEAD_COMMIT. The v6.x entry has null values since v6 has no npm release yet, these get filled automatically by release.yml when webpack tags a v6 release.

What kind of change does this PR introduce?

New file, no existing behaviour is modified.

Did you add tests for your changes?

Tests will come alongside update-versions.mjs which reads and mutates this file. Adding them here in isolation would not be meaningful without the script that uses it.

Does this PR introduce a breaking change?

No. Nothing currently depends on this file.

If relevant, what needs to be documented?

Schema is already documented and shared with the team.

Use of AI

Used for writing the PR Desc.

View on GitHub

readme fetch automation - with this now pulls readme content of all the loaders and plugins available in the webpack ecosystem on its own instead of someone copy pasting it in manually.

feat: automate fetching and sanitization of webpack ecosystem readmes #122

ryzrr posted on Jun 05, 2026

Issue Link : #103

Summary Introduced fetch-readmes.mjs which fetches the readme of all loaders and plugins present in the webpack org and passes the md file to pipeline to generate the documentation.

What kind of change does this PR introduce? New Feature (Build/Automation Script).

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, for testing and refinement of the regex and sanitization logic

View on GitHub

release-triggered version sync - A .yml file, this is the one that keeps everything aware of the version(latest one) a github actions workflow that watches for new release tags on the core webpack repo, then raise a PR with the updates versions.json, and opens up for maintainer review. vercel grabs that PR and rebuilds the docs. so a new release basically ships updated docs on its own now. feels like magic, is not magic, is just yaml.👌

two bugs that i encountered during my week (briefly)

remark-alerts had edge cases , like there where no support for github remarks. spent way too long assuming i was doing something wrong before realizing it just wasn't handled. filed a feature request upstream on nodejs/doc-kit instead of duct-taping around it. Thanks to my mentor , who helped me figured the root issue for this.

feat(remark): add alert support #832

avivkeller posted on Jun 06, 2026

Fixes #831:

View on GitHub

shiki was silently failing builds on languages it didn't support. no error, no warning, just a build that quietly didn't work. found it by accident honestly 😅. glad it was now and not three weeks from now when someone else hits it in prod. Again my mentors help me out , they raised an upstream PR for it and fixed the issue.🙇

fix(shiki): fallback to plaintext on unknown lang #8952

avivkeller posted on Jun 06, 2026

In the event that an unknown language is added, we should fall back to text, rather than fail the entire build

View on GitHub

what's next

tightening up CI checks and syncing more with my teams as our pieces start overlapping. probably more to say about that next time.

that's it for post one. short and sweet, like my attention span this week.
will be back, shortly - ryzrr!