Refactor website builder to provider-based architecture

[Copilot]

The website builder was hardcoded to Pelican with fixed directory structures, mappings, and exclude patterns. This refactoring introduces a provider system enabling arbitrary static site generators (Sphinx, Hugo, Yew/WASM, etc.).

Architecture

Providers (providers.bzl):

• WebsiteAssetInfo(files, asset_type, prefix) - Type-tagged assets
• WebsiteGeneratorInfo(executable, accepts, output_path, dev_server) - Generator capabilities

Typed Assets:

# bazel/website/content/markdown.bzl
markdown_assets(
    name = "docs",
    srcs = glob(["**/*.md"]),
    asset_type = "markdown",  # Semantic typing
)

Generator Rules:

# bazel/website/generators/sphinx.bzl
sphinx_generator(
    name = "sphinx",
    accepts = ["rst", "markdown", "sphinx_theme", "css", "js", "static"],
)

static_website(
    name = "site",
    content = ":docs",
    generator = ":sphinx",  # Any generator, not just Pelican
)

Implementation

• Dual output: Asset rules produce both WebsiteAssetInfo (new) and pkg_files (backwards compat)
• Optional introspection: static_website macro enhanced to support provider-based generators while maintaining existing behavior
• Skeleton generators: Mock, Sphinx, and Yew implementations prove extensibility for testing, RST, and WASM workflows

Structure

bazel/website/
├── providers.bzl           # Provider definitions
├── assets.bzl              # Base asset rule
├── content/                # markdown_assets, rst_assets
├── templates/              # jinja_templates, rst_templates
└── generators/             # pelican, mock, sphinx, yew

Existing Pelican-based static_website() calls require no changes. Asset type matching and routing happen transparently when using provider-enabled generators.

Original prompt

Overview

Refactor the Bazel website builder to use a provider-based architecture that makes the system extensible to different static site generators (Pelican, Sphinx, Yew/Rust, etc).

Current State

The existing static_website macro in bazel/website/macros.bzl works but is Pelican-shaped:

• Hardcoded mappings, exclude patterns, and directory structure assumptions
• website_theme macro has hardcoded field names (css, js, images, templates)
• Only Pelican generator is supported

Desired Architecture

1. Provider Layer (bazel/website/providers.bzl)

WebsiteAssetInfo = provider(
    fields = {
        "files": "depset of files",
        "asset_type": "string identifier (markdown, jinja, rst, scss, static, rust_component, etc)",
        "prefix": "mount point in source tree",
    }
)

WebsiteGeneratorInfo = provider(
    fields = {
        "executable": "the build tool",
        "accepts": "list of asset_types this generator handles",
        "output_path": "where it puts output",
        "dev_server": "optional dev mode executable",
    }
)

2. Typed Asset Rules (semantic directory structure)

bazel/website/
├── providers.bzl           # WebsiteAssetInfo, WebsiteGeneratorInfo
├── assets.bzl              # base asset rule, static_assets
├── templates/
│   ├── BUILD
│   ├── jinja.bzl           # jinja_templates rule
│   └── rst.bzl             # rst_templates
├── content/
│   ├── BUILD
│   ├── markdown.bzl        # markdown_assets
│   └── rst.bzl             # rst_assets
├── generators/
│   ├── BUILD
│   ├── pelican.bzl         # pelican_generator
│   ├── sphinx.bzl          # sphinx_generator (skeleton)
│   ├── yew.bzl             # yew_generator (skeleton)
│   └── mock.bzl            # mock_generator for testing

Each asset rule (e.g., markdown_assets, jinja_templates) produces WebsiteAssetInfo with the appropriate asset_type.

3. Generator Rules

Each generator declares what asset types it accepts:

pelican_generator(
    accepts = ["markdown", "rst", "jinja", "scss", "css", "js", "static"],
    ...
)

sphinx_generator(
    accepts = ["rst", "markdown", "sphinx_theme", "css", "js", "static"],
    ...
)

yew_generator(
    accepts = ["rust_component", "css", "js", "static", "wasm"],
    ...
)

4. Combiner Logic

The static_website rule introspects WebsiteAssetInfo from deps, matches against generator's accepts, warns on mismatches, and assembles the build.

Requirements

a) Existing tests must not break

• All tests in bazel/website/tests/ must continue to pass
• The current static_website macro with Pelican must keep working (backwards compatibility)

b) Add obvious new tests

• WebsiteAssetInfo provider is correctly attached by asset rules
• WebsiteGeneratorInfo provider is correctly attached by generator rules
• Asset type matching/filtering works (accepted types pass through)
• Aggregation preserves provider info

c) Add speculative extensibility tests (must pass)

• A "mock" or "echo" generator that validates it receives correct asset types
• Test that mixing asset types shows the routing works correctly
• Minimal sphinx_generator skeleton proving the wiring works
• Minimal yew_generator / rust_assets skeleton proving WASM path is viable
• These tests prove "if someone adds Sphinx/Yew support later, the framework supports it"

Implementation Notes

• Keep macros.bzl as the backwards-compat entry point
• New rules should produce both existing pkg_files compatible output AND new providers for backwards compat
• The mock generator for tests can be a shell script that echoes what asset types it received and validates expectations

This pull request was created from Copilot chat.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[netlify]

✅ Deploy Preview for nifty-bassi-e26446 ready!

Name	Link
🔨 Latest commit	cb64342
🔍 Latest deploy log	https://app.netlify.com/projects/nifty-bassi-e26446/deploys/6979380e6e46b40008ce1722
😎 Deploy Preview	https://deploy-preview-3637--nifty-bassi-e26446.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.