examples/moonbit_component hard-fails to LOAD (unlike test/moonbit's graceful degradation) — forces CI to avoid bazel test //... #637

Summary

examples/moonbit_component/BUILD.bazel directly load()s @rules_moonbit//moonbit:defs.bzl, which isn't registered as a dependency by default (MoonBit's toolchain source, pulseengine/rules_moonbit, is archived and was never eagerly loaded here — rolling /latest/ URLs caused checksum drift; see artifacts/stpa.yaml's mitigated loss-scenario for that history). Confirmed directly:

$ bazel query //examples/moonbit_component/...
ERROR: ... Unable to find package for @@[unknown repo 'rules_moonbit' ...]//moonbit:defs.bzl:
The repository '@@[unknown repo 'rules_moonbit' ...]' could not be resolved...

This is a load-time failure, not a build-time one — it happens even for bazel query, before any toolchain resolution.

Why this is worth fixing on its own

test/moonbit/... — which also needs the MoonBit toolchain — does not fail this way; bazel build //test/moonbit/... resolves cleanly to 0 buildable targets (graceful degradation), matching this repo's existing pattern for other optional/BYO-toolchain languages (componentize-py is "not eagerly loaded" the same way). Only the example hard-fails at load.

This is exactly why .github/workflows/release.yml already carries a workaround:

# release_ruleset defaults to `bazel test //...`, which fails to LOAD this
# repo's optional/lazy-dep example packages (e.g. examples/moonbit_component
# needs @rules_moonbit, deliberately not eagerly fetched). Build the core
# rule packages only ...
bazel_test_command: "bazel build //wasm/... //wit/... //rust/... //go/... //cpp/... //js/... //providers/..."

Proposed

Make examples/moonbit_component degrade the same way test/moonbit already does, so bazel test //... (and the release workflow's default) works without the explicit target-list workaround. Options, roughly in order of how much they touch:

1. Add examples/moonbit_component to .bazelignore (same pattern already used for examples/varve_extension, a standalone-module example) — simplest, if the example is meant to demonstrate BYO-toolchain usage rather than build in this repo's own CI.
2. Restructure the example so the @rules_moonbit load is conditional/guarded the same way moonbit/private/*.bzl's rule implementations already are (they only touch @rules_moonbit//moonbit:moonbit_toolchain_type inside rule implementations, not at load time — that's why test/moonbit loads fine).

Bigger, separate question — not proposing this here

Whether the whole //moonbit language backend (rule implementations + example + tests) should be removed entirely, given its only upstream toolchain source is now archived, is a bigger call — it's public rule surface in a BCR-published ruleset, and test/moonbit's graceful-degradation design suggests it was meant to be legitimate BYO-toolchain-optional support (like componentize-py) rather than simply abandoned. Flagging that question here for a maintainer decision, not proposing an answer.

🤖 Filed by Claude Code while investigating pulseengine/rules_moonbit and pulseengine/moonbit_checksum_updater archival status (both already archived, zero open PRs/issues on either).