Advice with some linting messages

[Poshi (Jordi)]

I’m using VSCode to codify my Nextflow pipelines and with the last updates I started getting some linting. Good!
Now I’m wondering about the meaning of some of the messages, but I will start with some comments and opinions.

It complained me about the ordering of the labels of a sub-workflow. I defined them like in a process: inputs, outputs and script (take, emit, main), but it looks like the linter do not like it and wants a different sorting: inputs, script, outputs. Besides the fact that I don’t like it that way (I prefer to have the workflow signature in a single location, like with any method where you have the function name, the inputs and the output type in the same line), it is not consistent with the ordering of the processes, where the input-output-script schema is kept.

Another thing that I don’t like is that it complains about the variable names defined in a map that are not used, and tells me to prepend an underscore to avoid the warning. This again goes against the style of the script where other variables have their name without additions. And having to add and remove the underscore when you start to use that variable seems to be tedious.

And finally, my doubts.

I’m getting a few Groovy-style type annotations are ignored in a method definition written in Java:

def process_file(bgzip_file) {
    File bgz_file = new File("$bgzip_file");
    long bgz_fileSizeInBytes = bgz_file.length();
    .
    .
    .

The method works perfectly and the variable types are well defined. But the complain is about the File and long qualifiers. What should I do? What the linter is expecting? I cannot see any issue with the current code, and I foresee compilation errors if I don’t declare those variables :-?

Another thing that scares me is a warning in the nextflow.config: Unexpected input: 'def'.
I’m defining a method to check and limit the resources requested by the different processes. I think this is a method widely used, but it looks like it is “unexpected”:

def check_max(obj, type) {
.
.
.

Any clue about what to do with this warning?

[bentsherman (Ben Sherman)]

Hi Jordi,

The language server enforces a stricter version of the Nextflow language. It will eventually be incorporated into Nextflow itself so that they are at parity, but until then, some issues flagged by the language server will not be actual errors at runtime.

I recommend you read through the Syntax Guide in the Nextflow+VSCode docs, which describes some of the common things that the language server will flag.

To address some points that aren’t covered in the docs:

• The check_max() function can be replaced with the resourceLimits directive (see the docs for details)

• Workflow labels should always be ordered as take → main → emit. You can see just the takes/emits by hovering over the workflow call in VSCode, same thing for processes. Note also that process outputs can be specified before or after the script (docs).

[Poshi (Jordi)]

You are right, none of the warnings/errors I got were errors at runtime and everything ran smoothly. But I like to solve all the linter errors, as they are usually indicators of bad practices or code smells that will lead to issues sooner than later.

The resourceLimits is something new that I didn’t had time yet to implement. But the question then would be: what if I need/want to implement tome method to perform some calculation in the config file? Like a method to generate the folder of the published files depending on their metadata? That should also be a def function() {...}, right? And the issue will be the same. I see in the doc that you linked that there can be some juggling done with the includeConfig statement… I’ll fight with it when I need it

Regarding the order of the workflow labels, the docs do not say anything about ordering of the sections; and I stand with my point: if you don’t have the help of an IDE that can show you the workflow signature (like when you open the file from a terminal), you will have a hard time to see which are the outputs of a workflow. But it’s up to you how do you define the syntax. Just have this issue in mind when discussing the topic.