I have installed the vscode extension right away after they released it and I have a bad experience about this.
There are no DAG preview, Code navigation as their blog said and when I open my nextflow repo, there are so many red color. I don’t know why def keyword is a error warning. Almost of my all nf get error warning although I can run it so many times. I think it can be better by let the users to turn off the warning color or warning function.
Hi @Kim_Huy_Vo.
Can you confirm on your extensions tab in VS Code that you have version v1.0.0?
You’re supposed to see the reason for the warning by hovering your mouse over the highlighted part.
You’re aware the Preview Dag button will only be displayed above subworkflows and workflows, right?
Lots of warnings are simply warnings. The code will still run, but you should instead do it differently.
I think it can be better by let the users to turn off the warning color or warning function.
You mean only highlighting errors, and ignoring warnings/suggestions?
One common warning for def statements is the one below:
Hi Kim,
Please refer to the new VS Code page in the Nextflow docs:
https://nextflow.io/docs/latest/vscode.html#syntax-guide
The Syntax Guide will walk you through some common issues you may encounter for both scripts and configs. If you follow the suggestions here, you should be able to quickly eliminate most of the errors.
Specifically, the import statements in your screenshot need to go. You can just use the fully qualified names in your code directly (as you are already doing with java.text.SimpleDateFormat.
There’s a new podcast episode going out today where we walk through exactly this problem and more: The Nextflow Podcast, by Seqera | The home of open science
Related to this - Is it possible to prevent evaluating certain lines of code, using something equivalent to # noqa for Python?
Currently, no, @risoms.
Is there any plan on allowing the suppression of incorrect linter warning or errors @mribeirodantas?
If you are seeing incorrect errors/warnings then I would prefer to not show them in the first place
Something maybe worth clearing up here:
Currently, the language server / VS Code extension enforces a stricter syntax than the Nextflow CLI. This means that VS Code may show something as an error, but the pipeline runs fine with Nextflow.
This is not an incorrect linter error. At least - not for long.
The language server code will soon be incorporated into Nextflow itself, so in the months to come the two will converge and anything you see currently as an error in VS Code will also be an error in the Nextflow CLI.
So hiding or ignoring these errors in VS Code now is a bad idea, as if they are there now then your pipeline will crash with the Nextflow CLI in the future (next year some time).
One or two small errors in your pipeline can cause a lot of red underlines. If you have a syntax error in a subworkflow, then that will also show red in the include statement and propagate through much of your pipeline.
Often, clearing up one or two small errors will result in a lot of red underline dissapearing.
Some of the errors in your screenshots come from code that is in the nf-core pipeline template (eg. def trace_timestamp). Many such errors have already been solved and the final ones will soon be gone. We will try to ensure that they are all done before the next release of the nf-core template, so updating to that when it is released will help.
The two errors in the screenshots appear to both be covered by the docs that @bentsherman linked to:
Import declarations
In Groovy, the import declaration can be used to import external classes:
import groovy.json.JsonSlurper def json = new JsonSlurper().parseText(json_file.text)Instead, use the fully qualified name directly:
def json = new groovy.json.JsonSlurper().parseText(json_file.text)
Currently, Nextflow parses config files as Groovy scripts, allowing the use of scripting constructs like variables, helper functions, and conditional logic for dynamic configuration.
The strict config syntax does not support functions, and only allows statements (e.g., variables and if statements) within closures.
In other words, you can’t have def in a config file any more.
I hope this clears things up and helps you resolve the errors. Although when first opening existing projects with the new VS Code extension the errors and warnings may look intimidating, hopefully they should not take long to fix and it will ensure that your pipeline is using Nextflow code best practices and will need minimal fixes in the future.
Phil
Just to clarify -
The error Unexpected input: '+=' reported for the snippet below from nextflow.config, although it works currently, is expected to crash with the Nextflow CLI when this convergence between the language server code and Nextflow occurs.
process {
...
resourceLabels = [
'Project': 'NextflowPipeline'
]
withName: denovo_assembly {
resourceLabels += ['pipeline:module': 'denovo_assembly']
}
...
}
Yes. Although we will almost certainly introduce the strict syntax into Nextflow as an opt-in feature at first, so that the new version doesn’t break your pipelines out of the gate.
@risoms I created a GitHub issue about doing // noqa statements by the way. I’m not expecting this one to be completed any time soon, but you can at least subscribe to updates on the issue now if you’d like: