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 scriptscripts/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
- 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/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.
- 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}`;
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!
ryzrr
posted on