The inert stub written when hook consent is not granted was
`export default async () => ({})`. OpenCode v2 validates every plugin
module before running it and requires the default export to be a definition
object with an `id` and an `effect` or `setup` function, so a declined or
runtime-less home install printed the same startup error as the V1 hook
plugin:
PluginModule.LoadError: Plugin must export a default definition with an id
and an effect or setup function.
(cause: SchemaError(Expected object at ["default"]))
Write `export default { id: "ecc-hooks", setup() {} }` instead. It keeps the
inert behaviour (no imports, no module initialization of the replaced
plugin) and satisfies the loader.
Tests that pinned the generated bytes now compare against
getDisabledOpenCodePluginContent() rather than a duplicated literal, and
tests/opencode-plugin-loader-contract.test.js asserts the loader contract on
the generated payload. That test fails on the previous stub
("default export must be an object, got function").
Refs #3537. The same assertion should cover .opencode/plugins/*.ts once a V2
entrypoint lands (#3536, #3224); those plugins are scanned independently in
home installs, so both the barrel and the implementation are loaded.
Address review findings on #3590:
- Unterminated block comments now throw instead of silently passing:
{'plugin':[]} /* no longer parses, so the install keeps its
source-context error for genuinely malformed configs (CodeRabbit,
Greptile).
- Line-comment scanners stop at CR as well as LF, so CR-only line
endings do not consume the rest of the file (CodeRabbit).
- activationIsInactive restores the 'plugin must be an array' shape
check that the strict parser surfaced, so a non-array plugin no
longer counts as inactive (Greptile).
Regression tests: unterminated comment with source context, CR-only
endings, and non-array plugin across apply/repair/doctor modes.
The read-only plugin-membership check in activationIsInactive and the
validation inside disableOpenCodeHookPluginRegistration used strict
JSON.parse, so any user whose ~/.config/opencode/opencode.json contains
JSONC comments (which OpenCode itself accepts) could not install the
OpenCode catalog. The plan never writes the user-owned config; this
parse is purely a membership read (issue #3546).
Add a string-aware JSONC parser (line/block comments, the trailing
commas they hide, URL strings untouched) and route both call sites
through it. Truly malformed JSON keeps its source-context error.
Tests: unit coverage for comment/trailing-comma/URL handling, plus an
apply-level regression test that installs over an inactive JSONC user
config byte-for-byte, across default and declined consent modes.
Preserve contributor history and current-main behavior while resolving the exact reviewed follow-up.
Source-PR: https://github.com/affaan-m/ECC/pull/3008
Source-Parent: d0dc1fcb08
Review-Manifest-SHA256: 8f15febd33dfa9f9ac6e70cb41f75ffee7aca47dd21782e841c33d4874341d6e
Keep historical fingerprints independent of source discovery and normalize explicit repository roots at doctor and repair entry points. Preserve unknown user plugins and absolute-only low-level source probing.
Source-PR: https://github.com/affaan-m/ECC/pull/3008
Reviewed-Manifest-SHA256: fe1444b12dfb730524970a51b6bb805271cdfa71d4cc9b247772e6d9b1d1c9d8
Attribute unrecorded OpenCode aliases only to exact trusted ECC source or build bytes while keeping planned and recorded destinations strict. Pass the trusted source root through repair plans and preserve unrelated user plugin files.
Ali Arslan