Question
Is the dependency on bazel-file-ops-component still wanted, or should it be replaced/dropped?
Asking because we are archiving dormant repositories across the org, and this one is not archivable while rules_wasm_component consumes it — so the decision belongs here, not there.
What we found
The dependency is real and load-bearing, not vestigial — 18 files reference it:
MODULE.bazel:305-320 — fetches file_ops_component.wasm from the component's GitHub releases and registers //toolchains:file_ops_toolchain_target
tools/bazel_helpers/file_ops_actions.bzl — invokes the component as the action executable
checksums/tools/file-ops-component.json — pins v0.2.0
CLAUDE.md documents the wiring as the reference example of the external-tool checksum pattern
Why we are asking anyway
The upstream is dormant and pinned to an old release:
|
|
| last push |
2026-05-10 (~3 months) |
| pinned version |
v0.2.0, released 2025-11-01 — 9 months ago |
last_checked in the pin file |
2025-11-01 |
| open issues upstream |
4 |
So rules_wasm_component depends on a component that nobody has touched in months, at a version nobody has revisited in nine. That is fine if it is done — a small, stable tool that does its job needs no commits. It is not fine if it is stalled.
The three answers we can act on
- Still wanted, and it is done. We leave it active, and note explicitly that dormancy is intentional rather than neglect — worth writing down so the next audit does not re-ask.
- Still wanted, but it needs work. Then the 4 open upstream issues and the 9-month-old pin are the backlog, and it should not be treated as dormant.
- No longer wanted. Tell us what would replace it (native Bazel actions? a different component?), and once
rules_wasm_component drops the dependency, the repo gets archived.
No action is being taken on the dependency without an answer here — this is a question, not a deprecation notice.
🤖 Filed during an org-wide repository resync (dormant-repo sweep + org profile cleanup).
Question
Is the dependency on
bazel-file-ops-componentstill wanted, or should it be replaced/dropped?Asking because we are archiving dormant repositories across the org, and this one is not archivable while
rules_wasm_componentconsumes it — so the decision belongs here, not there.What we found
The dependency is real and load-bearing, not vestigial — 18 files reference it:
MODULE.bazel:305-320— fetchesfile_ops_component.wasmfrom the component's GitHub releases and registers//toolchains:file_ops_toolchain_targettools/bazel_helpers/file_ops_actions.bzl— invokes the component as the action executablechecksums/tools/file-ops-component.json— pins v0.2.0CLAUDE.mddocuments the wiring as the reference example of the external-tool checksum patternWhy we are asking anyway
The upstream is dormant and pinned to an old release:
last_checkedin the pin fileSo
rules_wasm_componentdepends on a component that nobody has touched in months, at a version nobody has revisited in nine. That is fine if it is done — a small, stable tool that does its job needs no commits. It is not fine if it is stalled.The three answers we can act on
rules_wasm_componentdrops the dependency, the repo gets archived.No action is being taken on the dependency without an answer here — this is a question, not a deprecation notice.
🤖 Filed during an org-wide repository resync (dormant-repo sweep + org profile cleanup).