Astro contributor checks: runtime boundaries and isolated builds
Check Astro contributor guidance with real lint and build evidence: distinguish Node API boundaries, runnable examples, shallow immutability and separate build outputs.
Choose the contributor skill for the right task
The official Astro monorepo developer skill helps contributors navigate Astro's architecture, constraints, debugging and tests. It is a context guide for work on the framework repository, rather than a general website-generation recipe. This package pins the official withastro/astro snapshot to 28e74103fe3d999a56ae3404b5fe67a1ad6d8013. Its original instructions, four companion guides and evaluation prompts are retained together with linked repository context and the complete MIT notice.
BB Skills recorded 46 scoped observations on Windows using Node 24.10.0, Biome 2.5.3 and Astro 7.3.7. The fixed repository snapshot and the separately installed Astro release have different identities. Nine original documentation blocks were processed unchanged before Node's type erasure. A clearly labeled independent harness supplies imports, synthetic inputs and build pages. These results are not an upstream endorsement, a complete skill execution or proof that all contributor guidance works on every Astro version.
Test the runtime boundary with the actual rule
The repository's original biome.jsonc restricts Node modules in runtime folders and files whose names contain runtime. Our experiment used that exact configuration, with Git lookup disabled only through a CLI flag. The same unchanged five-import example produced five noNodejsModules diagnostics in each tested runtime location. The two tested build/plugin locations produced no diagnostics from that specific rule.
| Tested source location | Node API rule observations | What follows |
|---|---|---|
| Runtime server and runtime client folders | Five diagnostics in each location | The fixed configuration rejects these five Node imports there. |
| Vite plugin runtime.ts and core runtime-utils.ts | Five diagnostics in each location | A plugin directory does not exempt a runtime-named file. |
| Plugin implementation and core/build sample | Zero diagnostics from this rule | This rule did not reject the imports; other lint checks still reported unused imports. |
| Generated runtime module with a Node file import | One diagnostic | Lint the generated module itself rather than inferring portability from its generator. |
| Generated JSON-only runtime module | Zero diagnostics from this rule | The tested output has no Node imports; edge execution remains untested. |
Zero diagnostics from one rule is not a complete lint pass. This distinction matters because a successful local Node build can hide assumptions that fail in another runtime. The original bad plugin stores a Node import inside generated source text; that text is not an executed import in the plugin implementation. We inspected and linted its emitted module without running its file read. The experiment did not run Cloudflare Workers or Deno.
Check an example before reusing it
Documentation often places a bad pattern next to a better one. The unchanged buildRoutes comparison defines the same exported function twice. It fails ESM parsing after type erasure, so the entire comparison should not be pasted into an executable module. Choose an implementation and supply its actual dependencies when adapting it.
The original Markdown sample has a second concrete limit: splitting the synthetic frontmatter input retains a leading newline. Its own unchanged unit assertion expects the transformed text without that newline and fails. The observation records the actual value \nNOTE: Fix this with a leading newline; the package preserves the original assertion instead of silently repairing it. A separate observation records a TypeError when the input has no frontmatter delimiters.
These counterexamples identify missing assumptions. Define whether leading whitespace should be preserved and whether frontmatter is required before writing acceptance tests. A production Markdown parser also needs explicit behavior for malformed or repeated delimiters. Neither the sample function nor this small experiment establishes a complete Markdown parser.
Separate file effects and shared references
The original configuration and Markdown examples separate transformation functions from file I/O. We executed both the coupled and separated infrastructure functions on synthetic files, and checked missing-file propagation. The extracted configuration function returns a new object and preserves existing fields, but its nested object remains shared with the input.
The manifest example makes the same distinction: the better function returns a new routes array and leaves the original count and version unchanged. The new array still contains the original route object. The contrasting function mutates the input directly. If your task requires deep immutability, shared nested references need additional treatment and tests; a new outer object or array alone does not provide it.
The original manifest unit assertion passed in the native Node test runner. The original Markdown unit assertion failed as described above. The evidence labels both outcomes explicitly and does not report the unmodified upstream test pair as an all-green suite.
Build the original virtual-module plugin
Two real standalone Astro builds used the unchanged build-time JSON plugin from the constraints guide. The plugin reads a synthetic local configuration and emits JSON-only source for a virtual module. Independent BB Skills pages import that module and render the supplied title and nested label. This is actual Astro/Vite integration evidence for that plugin in the tested release, rather than a mock plugin result.
Each build used its own output and cache directory. The second build rendered the changed synthetic title while the first HTML file retained its exact SHA-256. Both outputs had English HTML, a single H1 and the explicitly configured fixture canonical URL. Astro also escaped the synthetic script text in the first title. These are checks of the generated fixture pages, not an audit of every Astro application's SEO or security.
The independent preload disabled telemetry and denied JavaScript HTTP/socket connections during the two builds; it recorded zero connection attempts. The original skill's loadFixture helper and full monorepo runner were not used. Separate output preservation does not reproduce or rule out the monorepo's ESM cache-pollution issue.
Choose evidence that matches the claim
| Question | Useful evidence | This experiment's boundary |
|---|---|---|
| Does a pure transformation preserve the required fields? | Input, output and mutation assertions | Executed original configuration, Markdown and manifest examples with synthetic inputs. |
| Does repository lint reject a Node import here? | The actual rule, file path and diagnostics | Used the fixed Biome configuration and recorded other diagnostics separately. |
| Does the plugin work in an Astro build? | Real build output and the tested versions | Two standalone static builds using the original JSON virtual-module plugin. |
| Does it work in every Astro pipeline or edge adapter? | Tests for the actual pipelines and runtime targets | Not tested; no all-pipeline or edge compatibility claim. |
| Does hydration or interaction work in a browser? | Browser behavior in the relevant project | Not tested by this fixture; choose a browser workflow separately. |
Use the Vite configuration workflow when reviewing plugin setup, and the Vitest workflow when designing a different test suite. This experiment itself uses Node's native test runner, not Vitest. The Playwright CLI resource can support later browser checks. The Svelte practices resource covers adjacent component behavior; linking these resources does not assert that their integrations were jointly tested.
Reproduce the recorded scope
Inspect the source and license notices, verify the package checksum, and extract it into an independent working directory. The recorded fixture uses Node 24.10.0; its type-erasure API is experimental. The Astro package's broader Node engine requirement is not proof that this harness works on every supported Node release. Installed dependencies and generated outputs are excluded from the skill download.
npm ci --ignore-scripts --no-audit --no-fund
node examples/run_fixture.mjsThe dependency installation contacts the free public npm registry. The experiment then writes only its own synthetic files and outputs under .generated. It starts no preview server and needs no account, API key, database or paid service. Inspect examples/fixture-evidence.json for original block hashes, exact tool versions, named observations, diagnostics and output hashes. A new run produces new evidence; the included record describes the original run.
Verify your project before adopting the skill
For framework contributions, use the complete matching Astro checkout and its current contributor instructions. The package retains selected linked repository documents as context, but does not contain the entire monorepo, every integration, changeset tooling or a working checkout. Its evaluation prompts are source material and were not executed. Node type erasure is not a full TypeScript typecheck.
Check request-state ownership, production manifests, adapter constraints and all relevant pipeline variants in your actual feature. Keep browser, cache-isolation, edge-runtime, authentication and performance claims separate from lint or static-build results. A package checksum establishes file identity, not safety or correctness of every instruction.
Sources: the fixed official Astro skill snapshot, its retained companion guides and repository MIT notice, Astro's experimental programmatic API, and the Biome CLI reference. BB Skills wrote this guide and independent fixture with AI assistance, checked the results, and states their limits. It is not an Astro certification or a complete AI-client skill run.