Hey, ryzrr back 🙌. a lot shipped since the last post so let's get into it.
what i shipped
-
- governance docs fetcher, pulls webpack governance docs at build time and renders them under
feat: add governance docs fetcher under pages/contribute/governance
#127
ryzrr posted onSummary Adds a script
scripts/markdown/governance.mjsthat 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
/about/governance -
- CI now builds the site on every PR and uploads the artifact for downloadble version.
ci: run site build on PRs
#146
ryzrr posted on
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
-
- release banner, auto-script approach got dropped in favour of a hand-edited self-documenting JSON config
feat(banner): show latest webpack release instead of Node.js banner
#151
ryzrr posted on
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
-
/ #157 - CodeQL and zizmor scanning, both merged clean
ci: add CodeQL scanning
#155
ryzrr posted on
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
-
- version picker on API docs + sidebar active-state fix
fix : version picker to the API docs and highlight the overview as active
#160
ryzrr posted on
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
-
- loaders and plugins index landing pages
feat(docs): add loaders and plugins index pages
#153
ryzrr posted on
This adds the loaders and plugins index pages, so
/docs/loadersand/docs/pluginsfinally 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. -
- resolved guide TODO placeholder links to plugin API references
fix(docs): resolve the guide TODOs for the plugin to its API references
#163
ryzrr posted on
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.
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!
Top comments (0)