Nextflow strict syntax for non-nf-core-modules/workflows

[d4straub]

All warnings and errors with

NXF_VER=25.10.2 nextflow lint ampliseq -exclude ".git,.nf-test,nf-test.config"
NXF_VER=25.12.0-edge nextflow lint ampliseq -exclude ".git,.nf-test,nf-test.config"

were fixed in non nf-core modules and subworkflows. Some modules and the nf-core subworkflow fasta_newick_epang_gappa are still having warnings.

NXF_VER=25.12.0-edge NXF_SYNTAX_PARSER=v2 nextflow run ampliseq --help
was fixed via an update of the subworkflow utils_nfschema_plugin, but it still warns about:

WARN: Unrecognized config option 'validation.defaultIgnoreParams'
WARN: Unrecognized config option 'validation.monochromeLogs'

PR checklist

• This comment contains a description of changes (with reason).
• If you've fixed a bug or added code that should be tested, add tests!
• If you've added a new tool - have you followed the pipeline conventions in the contribution docs
• If necessary, also make a PR on the nf-core/ampliseq branch on the nf-core/test-datasets repository.
• Make sure your code lints (nf-core pipelines lint).
• Ensure the test suite passes (nextflow run . -profile test,docker --outdir <OUTDIR>).
• Check for unexpected warnings in debug mode (nextflow run . -profile debug,test,docker --outdir <OUTDIR>).
• Usage Documentation in docs/usage.md is updated.
• Output Documentation in docs/output.md is updated.
• CHANGELOG.md is updated.
• README.md is updated (including new tool citations and authors/contributors).

[d4straub]

Linting issues are:

╭─ [✗] 3 Pipeline Tests Failed ────────────────────────────────────────────────╮
│                                                                              │
│ nf_test_content: 'nf-test.config' does not set a testsDir, it should contain │
│ testsDir "."                                                                 │
│ nf_test_content: 'nf-test.config' does not set a workDir, it should contain  │
│ workDir System.getenv("NFT_WORKDIR") ?: ".nf-test"                           │
│ nf_test_content: 'nf-test.config' does not set a configFile, it should       │
│ contain configFile "tests/nextflow.config"                                   │
│                                                                              │
╰──────────────────────────────────────────────────────────────────────────────╯

╭─ [✗] 1 Subworkflow Test Failed ──────────────────────────────────────────────╮
│                                 ╷                     ╷                      │
│ Subworkflow name                │ File path           │ Test message         │
│╶────────────────────────────────┼─────────────────────┼─────────────────────╴│
│ utils_nfschema_plugin           │ subworkflows/nf-co… │ check_local_copy:    │
│                                 │                     │ Local copy of        │
│                                 │                     │ subworkflow does not │
│                                 │                     │ match remote         │
│                                 ╵                     ╵                      │
╰──────────────────────────────────────────────────────────────────────────────╯

so either I satisfy linting with nextflow or linting wit nf-core...

Edit:

• 'nf-test.config' should not be changed -> reverted previous edit
• nf-core subworkflows update utils_nfschema_plugin fixes the utils_nfschema_plugin error

[erikrikarddaniel]

I don't understand the leading underscores in variable names, but otherwise this looks fine.

[erikrikarddaniel]

Why did you add an underscore to reads here but not to meta, but you did add to meta elsewhere? (Not to mention why add leading underscores at all, but that's some new guideline I suppose.)

[d4straub]

Whenever a variable is not used, i.e. here "reads" is dropped, nextflow lint gives a warning. This warning can be avoided by prepending an underscore. So its driven by the nextflow linting, as in the opening post. However, it seems to me to have also practical value by visualizing what information is dropped/not used (trivial here in that example, but can be more informative e.g. in subworkflow input).

[erikrikarddaniel]

I see, that makes sense.

[d4straub]

Thanks!