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

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. 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. 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. #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. #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.👌 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. #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.🙇 #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 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!