Skip to content

docs: document ConfigScope discovery rules#7098

Open
pinin4fjords wants to merge 3 commits intonextflow-io:masterfrom
pinin4fjords:docs/configscope-discovery-rules
Open

docs: document ConfigScope discovery rules#7098
pinin4fjords wants to merge 3 commits intonextflow-io:masterfrom
pinin4fjords:docs/configscope-discovery-rules

Conversation

@pinin4fjords
Copy link
Copy Markdown
Contributor

Summary

The plugin developer guide currently shows a single-option ConfigScope example with @ScopeName and a no-arg constructor, but does not mention registering the scope in build.gradle extensionPoints. Following the example as written does not eliminate Unrecognized config option warnings under the v2 syntax parser, because the scope is never discovered.

This PR fills four related gaps:

  • Documents the extensionPoints registration step required for the top-level scope to be discovered
  • Adds a nested-scope example, showing that fields whose declared type implements ConfigScope are auto-discovered and do not need a @ConfigOption annotation
  • Notes that @ConfigOption fields are not inherited (the validator uses Class.getDeclaredFields()), so each ConfigScope class must declare its options directly
  • Notes that the types attribute on @ConfigOption should only list standard Nextflow types, not runtime classes like GString, Number or Map

These rules are derivable from SpecNode.java and ConfigValidator.groovy, but were not surfaced for plugin authors. Context for the gap: nextflow-io/nf-co2footprint#362 and the related upstream issue #6974.

Style

The new content is additive; the existing single-option example is left intact. Triple-quoted @Description strings, :::{note} admonitions and prose voice match the surrounding section.

The existing example shows the top-level scope class but does not
mention registering it in `build.gradle` `extensionPoints`, which is
required for the v2 syntax parser to discover and validate the scope.
This addition:

- Documents the `extensionPoints` registration step
- Adds a nested-scope example showing that fields whose type implements
  `ConfigScope` are auto-discovered and do not need `@ConfigOption`
- Notes that `@ConfigOption` fields are not inherited (the validator
  uses `Class.getDeclaredFields()`)
- Notes that the `types` attribute on `@ConfigOption` should only list
  standard Nextflow types, not runtime classes like `GString` or `Map`

These rules can be inferred from the source (`SpecNode.java`,
`ConfigValidator.groovy`) or learned from reviewer feedback, but were
not previously documented for plugin authors.

Signed-off-by: Jonathan Manning <jonathan.manning@seqera.io>
@pinin4fjords pinin4fjords requested a review from a team as a code owner May 5, 2026 10:26
@netlify
Copy link
Copy Markdown

netlify Bot commented May 5, 2026

Deploy Preview for nextflow-docs-staging canceled.

Name Link
🔨 Latest commit d6bdd49
🔍 Latest deploy log https://app.netlify.com/projects/nextflow-docs-staging/deploys/69fb333bcb6b890008bd32b7

Trim the nested-scope content to better match the verbosity of
neighbouring sections:

- Drop the second `@ConfigOption` field from `ReportConfig`; one
  field is enough to demonstrate the pattern
- Drop the `types=` admonition; that rule is general `@ConfigOption`
  guidance rather than something specific to nested scopes, and the
  language server already surfaces it
- Tighten the inheritance note from four sentences to two

Signed-off-by: Jonathan Manning <jonathan.manning@seqera.io>
Comment thread docs/plugins/developing-plugins.md Outdated
Co-authored-by: Chris Hakkaart <chris.hakkaart@seqera.io>
Signed-off-by: Jonathan Manning <jonathan.manning@seqera.io>
@pinin4fjords pinin4fjords force-pushed the docs/configscope-discovery-rules branch from 69fb656 to d6bdd49 Compare May 6, 2026 12:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants