The Foundry book checks its own pages against the tool

A Vocs site with MDX content

The repository is the documentation for all things Foundry, and the published result is at getfoundry.sh. The primary language is recorded as MDX, which is the format Vocs uses to let a page mix Markdown with React components, and the site framework is vocs, with the dependency pinned to version 2.10.2. The content is React 19 with Tailwind 4, and the build tooling is vite-plus, with a Waku release candidate in the dependencies, which is what gives the site its static output and deployment story. The practical consequence for a reader is that the pages are real web pages with interactive components rather than a rendered document, which is what allows a cheatcode reference to include a runnable snippet or a comparison table that updates itself.

Adding a page means touching the sidebar

The contribution instructions are short and they are the whole workflow. You check the contributing guidelines, then feel free to contribute wording, sentences, chapters and guides, which is an unusually broad invitation that covers typo fixes and whole new chapters with the same process. The technical part is that the book is built with Vocs, dependencies are installed with pnpm, and to see the book change live you run pnpm dev:

pnpm install
pnpm dev

The one structural rule is that to add a new section, that is a file, to the book, you add it to sidebar.ts in the sidebar directory, which means the navigation is a TypeScript file rather than a directory listing. That is a deliberate choice, since it lets the sidebar be sorted and described, and it is also the one thing a contributor has to remember when a new page does not appear in the navigation. For a more structured view of the current issues, the README points at the GitHub project board for the organisation.

The check scripts are the interesting part

The package scripts are where this project stops being a documentation site and starts being an engineering artifact. Alongside the ordinary build, dev and preview scripts, there are checks with names that explain the approach. check-cheatcodes runs a script that checks cheatcode coverage, check-commands runs one that checks narrative commands, check-anvil-rpc-coverage checks the coverage of the Anvil RPC surface, and import:lints runs a script that imports lint documentation from somewhere. The pattern is that the pages are not trusted, and each check compares what the documentation says against what the tool provides. The fetch scripts work the other way, with fetch-benchmarks pulling benchmark data and fetch-changelog pulling the changelog, so parts of the site are generated from the project itself rather than written by hand. That is a design that keeps a large reference honest, because a documentation site that only describes what its authors remembered to describe is a documentation site that is wrong within two releases.

Documentation is tested like code

The test scripts follow the same logic. The test command runs unit tests for the fetch-benchmarks script and the import-lint-docs script, and then runs the tests for the performance sub-project, while a separate end-to-end script runs Playwright against the site. The end-to-end layer is the one that catches the failure mode a unit test cannot, which is a page that renders but renders wrong, or a link that points at a page that was renamed. The check command is broader still, since it runs the checker over the GitHub configuration, the end-to-end directory, the package file, the Playwright configuration, the pnpm workspace file, the scripts, the sidebar, the source components, the TypeScript configuration and the Vite and Vocs configurations, and then runs the checks for the performance project. The deployment scripts add a Vercel build, with the performance site built twice for two different projects, an evm2 and a solar build, and the project selected with an environment variable.

A separate performance sub-project

The repository contains a foundry-perf package, built and checked separately from the documentation, and it produces static output under a per-project path, with the two projects named solar and evm2 appearing in the deployment script. The perf/ directory at the top level, along with the fetch-benchmarks script and the benchmarks the site publishes, points to a project that measures something and then feeds the numbers into the documentation. The interesting engineering decision is that the numbers are not pasted in. If the benchmark script fails to fetch, the build fails, and if the numbers change, the page changes with them, so a reader looking at a performance table is looking at a measurement rather than a screenshot of one taken six months ago. It is also the reason the deployment has two performance builds, since the two projects are compared against each other.

The stack in one list

The dependency list is short for a site of this size, and each entry has a job. React and React DOM at 19.3 provide the components, Tailwind CSS 4.2.2 provides the styling, Vocs 2.10.2 provides the routing and the MDX pipeline, and Waku 1.0.0-rc.3 is the framework that produces the static output. On the development side, Playwright 1.64.0 drives the end-to-end tests, tsx runs the TypeScript check scripts directly without a separate build step, TypeScript 7.0.2 type checks, and the Vite React plugin 6.1.2 handles the client build, with Vite and vite-plus both taken from a catalog version rather than pinned individually. There is also a patches/ directory and a .gitmodules file, which usually means a dependency is patched locally, and that is worth knowing before you file a bug about something that looks like a framework issue. The site itself is deployed with a vercel.json, and the build output for the performance pages is written into a Vercel output directory.

Who maintains it and where it stands

The README carries a contributors section listing 115 contributors, and the interesting part is the roles, since the table distinguishes documentation, reviewed pull requests and maintenance as separate contributions. A large number of people are tagged for maintenance, which is what you would expect for a reference that has to track a toolchain shipping new cheatcodes regularly, and a smaller set are tagged for documentation work and for reviewing pull requests. The licence files in the repository are LICENSE-APACHE and LICENSE-MIT, so the repository carries both an Apache licence file and an MIT licence file. The repository is not archived, the last push was on 2026-10-19, and no GitHub releases are published, which is the expected shape for a documentation site, since the deployed version at getfoundry.sh is the artefact that matters and the commits are the history of it.

Editorial conclusion

The Foundry book fits a developer learning Foundry or a contributor adding a feature who needs the reference to be current, since the coverage checks mean a new cheatcode cannot be shipped without documentation catching up, or the build complains. It does not fit a reader who wants a narrative tutorial in one sitting, since it is a reference organised by page and sidebar rather than a course. It does not fit a team that wants to run the site itself, because the pipeline is tied to a monorepo with a specific deployment setup. Before you contribute, read the contributing guidelines, install the dependencies with pnpm, and expect the check scripts to run over the pages, which means a wording change can fail a check if it removes a command reference the coverage script looks for.

Frequently asked questions

Official sources

1. foundry-rs/book on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README