Merge branch 'master' into docs-azcopy-options

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,24 +1,23 @@
 ---
 name: Bug report
-about: Create a report to help us improve
+about: Report a bug to help us improve
 ---
 
 ## Bug report 
 
-(Please follow this template replacing the text between parentheses with the requested information)
+(Please follow this template by replacing the text between parentheses with the requested information)
 
 ### Expected behavior and actual behavior
 
-(Give an brief description of the expected behavior 
-and actual behavior)
+(Give a brief description of the expected behavior and actual behavior)
 
 ### Steps to reproduce the problem
 
-(Provide a test case that reproduce the problem either with a self-contained script or GitHub repository)
+(Provide a test case that reproduces the problem either with a self-contained script or GitHub repository)
 
 ### Program output 
 
-(Copy and paste here output produced by the failing execution. Please highlight it as a code block. Whenever possible upload the `.nextflow.log` file.)
+(Copy and paste the output produced by the failing execution. Please highlight it as a code block. Whenever possible upload the `.nextflow.log` file.)
 
 ### Environment 
 

.github/ISSUE_TEMPLATE/general_question.md

@@ -1,19 +1,8 @@
 ---
 name: General question 
-about: Need for help on Nextflow language and usage
+about: Ask for help with Nextflow language and usage
 ---
 
 Hi! Thanks for using Nextflow. 
 
-If you need help about Nextflow scripting language, 
-configuration options and general Nextflow usage the better 
-channels to post this kind of questions are: 
-
-* GitHub discussions: https://github.com/nextflow-io/nextflow/discussions
-* Slack community chat: https://www.nextflow.io/slack-invite.html
-
-
-Also you may also want to have a look at the patterns page 
-for common solutions to recurrent implementation problems: 
-http://nextflow-io.github.io/patterns/index.html
-
+If you need help using or developing Nextflow pipelines, the best place to ask questions is the [community forum](https://community.seqera.io/).

.github/ISSUE_TEMPLATE/new_feature.md

@@ -1,22 +1,16 @@
 ---
 name: New feature
-about: Submit a new feature proposal
+about: Propose a new feature or enhancement
 ---
 
 ## New feature
 
-Hi! Thanks for using Nextflow and submitting the proposal 
-for a new feature or the enhancement of an existing functionality. 
+(Hi! Thanks for using Nextflow and for proposing a new feature or enhancement. Please replace this text with a brief description of your proposal.)
 
-Please replace this text providing a short description of your 
-proposal.
+## Use case 
 
-## Usage scenario 
+(What's the main use case and deployment scenario addressed by this proposal)
 
-(What's the main usage case and the deployment scenario addressed by this proposal)
-
-## Suggest implementation 
+## Suggested implementation 
 
 (Highlight the main building blocks of a possible implementation and/or related components)
-
-

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

@@ -1,16 +1,7 @@
-Hi! Thanks for contributing to Nextflow project.
+Hi! Thanks for contributing to Nextflow.
 
-When submitting a Pull Request please make sure to not include
-in the changeset any modification in these files:
-
-* `nextflow`
-* `modules/nf-commons/src/main/nextflow/Const.groovy`
-
-Also, please sign-off the DCO [1] to certify you are the author of the contribution
-and you adhere to Nextflow open source license [2] adding a `Signed-off-by` line to
-the contribution commit message. For more details check [3].
+When submitting a Pull Request, please sign-off the DCO [1] to certify that you are the author of the contribution and you adhere to Nextflow's open source license [2] by adding a `Signed-off-by` line to the contribution commit message. See [3] for more details.
 
 1. https://developercertificate.org/
 2. https://github.com/nextflow-io/nextflow/blob/master/COPYING
 3. https://github.com/apps/dco
-

.github/workflows/build.yml

@@ -133,7 +133,7 @@ jobs:
       fail-fast: false
       matrix:
         java_version: [17, 23]
-        test_mode: ["test_integration", "test_docs", "test_aws", "test_azure", "test_google", "test_wave"]
+        test_mode: ["test_integration", "test_parser_v2", "test_docs", "test_aws", "test_azure", "test_google", "test_wave"]
     steps:
       - name: Checkout
         uses: actions/checkout@v4

build.gradle

@@ -85,6 +85,10 @@ allprojects {
         maven { url 'https://oss.sonatype.org/content/repositories/snapshots' }
         maven { url = "https://s3-eu-west-1.amazonaws.com/maven.seqera.io/releases" }
         maven { url = "https://s3-eu-west-1.amazonaws.com/maven.seqera.io/snapshots" }
+        maven {
+            url 'https://jitpack.io'
+            content { includeGroup 'com.github.nextflow-io.language-server' }
+        }
     }
 
     configurations {

docs/azure.md

@@ -342,14 +342,14 @@ When Nextflow creates a pool of compute nodes, it selects:
 
 Together, these settings determine the Operating System and version installed on each node.
 
-By default, Nextflow creates pool nodes based on Ubuntu 20.04, but this behavior can be customised in the pool configuration. Below are configurations for image reference/SKU combinations to select two popular systems.
+By default, Nextflow creates pool nodes based on Ubuntu 22.04, but this behavior can be customised in the pool configuration. Below are configurations for image reference/SKU combinations to select two popular systems.
 
-- Ubuntu 20.04 (default):
+- Ubuntu 22.04 (default):
 
   ```groovy
-  azure.batch.pools.<name>.sku = "batch.node.ubuntu 20.04"
-  azure.batch.pools.<name>.offer = "ubuntu-server-container"
-  azure.batch.pools.<name>.publisher = "microsoft-azure-batch"
+  azure.batch.pools.<name>.sku = "batch.node.ubuntu 22.04"
+  azure.batch.pools.<name>.offer = "ubuntu-hpc"
+  azure.batch.pools.<name>.publisher = "microsoft-dsvm"
   ```
 
 - CentOS 8:

docs/cli.md

@@ -223,16 +223,38 @@ These commands will execute two different project revisions based on the given G
 
 ### Pipeline parameters
 
-Pipeline scripts can use an arbitrary number of parameters that can be overridden using the command line or Nextflow configuration files. Any script parameter can be specified on the command line by prefixing the parameter name with double-dash characters. For example:
+Pipeline scripts can define *parameters* that can be overridden on the command line.
+
+Parameters can be declared in the main script:
+
+```nextflow
+params.alpha = 'default script value'
+
+workflow {
+  println "alpha = ${params.alpha}"
+}
+```
+
+Or in a config file:
+
+```groovy
+params {
+  alpha = 'default config value'
+}
+```
+
+The above parameter can be specified on the command line as `--alpha`:
 
 ```console
-$ nextflow run <pipeline> --foo Hello
+$ nextflow run main.nf --alpha Hello
 ```
 
-Then, the parameter can be accessed in the pipeline script using the `params.foo` identifier.
+:::{note}
+Parameters that are specified on the command line without a value are set to `true`.
+:::
 
 :::{note}
-When the parameter name is formatted using `camelCase`, a second parameter is created with the same value using `kebab-case`, and vice versa.
+Parameters that are specified on the command line in kebab case (e.g., `--foo-bar`) are automatically converted to camel case (e.g., `--fooBar`). Because of this, a parameter defined as `fooBar` in the pipeline script can be specified on the command line as `--fooBar` or `--foo-bar`.
 :::
 
 :::{warning}
@@ -245,14 +267,14 @@ $ nextflow run <pipeline> --files "*.fasta"
 
 Parameters specified on the command line can be also specified in a params file using the `-params-file` option.
 
-```bash
-nextflow run main.nf -params-file pipeline_params.yml
+```console
+$ nextflow run main.nf -params-file pipeline_params.yml
 ```
 
 The `-params-file` option loads parameters for your Nextflow pipeline from a JSON or YAML file. Parameters defined in the file are equivalent to specifying them directly on the command line. For example, instead of specifying parameters on the command line:
 
-```bash
-nextflow run main.nf --alpha 1 --beta foo
+```console
+$ nextflow run main.nf --alpha 1 --beta foo
 ```
 
 Parameters can be represented in YAML format:
@@ -271,7 +293,12 @@ Or in JSON format:
 }
 ```
 
-The parameters specified in a params file are merged with the resolved configuration. The values provided via a params file overwrite those of the same name in the Nextflow configuration file, but not those specified on the command line.
+Parameters are applied in the following order (from lowest to highest priority):
+
+1. Parameters defined in pipeline scripts (e.g. `main.nf`)
+2. Parameters defined in {ref}`config files <config-params>`
+6. Parameters specified in a params file (`-params-file`)
+7. Parameters specified on the command line (`--something value`)
 
 ## Managing projects
 

docs/config.md

@@ -6,18 +6,13 @@
 
 When a pipeline script is launched, Nextflow looks for configuration files in multiple locations. Since each configuration file may contain conflicting settings, they are applied in the following order (from lowest to highest priority):
 
-1. Parameters defined in pipeline scripts (e.g. `main.nf`)
-2. The config file `$HOME/.nextflow/config`, or `$NXF_HOME/.nextflow/config` when `NXF_HOME` is set (see [`NXF` prefixed variables](reference/env-vars.html#nextflow-settings)).
-3. The config file `nextflow.config` in the project directory
-4. The config file `nextflow.config` in the launch directory
-5. Config file specified using the `-c <config-file>` option
-6. Parameters specified in a params file (`-params-file` option)
-7. Parameters specified on the command line (`--something value`)
-
-When more than one of these options for specifying configurations are used, they are merged, so that the settings in the first override the same settings appearing in the second, and so on.
+1. The config file `$HOME/.nextflow/config` (or `$NXF_HOME/.nextflow/config` when {ref}`NXF_HOME <nxf-env-vars>` is set).
+2. The config file `nextflow.config` in the project directory
+3. The config file `nextflow.config` in the launch directory
+4. Config files specified using the `-c <config-files>` option
 
 :::{tip}
-You can use the `-C <config-file>` option to use a single configuration file and ignore all other files.
+You can alternatively use the `-C <config-file>` option to specify a fixed set of configuration files and ignore all other files.
 :::
 
 (config-syntax)=
@@ -129,16 +124,16 @@ The following functions are globally available in a Nextflow configuration file:
 Pipeline parameters can be defined in the config file using the `params` scope:
 
 ```groovy
-params.custom_param = 123
-params.another_param = 'string value .. '
+params.alpha = 123
+params.beta = 'string value .. '
 
 params {
-    alpha_1 = true
-    beta_2 = 'another string ..'
+    gamma = true
+    delta = "params.alpha is ${params.alpha}"
 }
 ```
 
-See {ref}`cli-params` for information about how to modify these on the command line.
+See {ref}`cli-params` for information about how to specify pipeline parameters.
 
 (config-process)=
 
@@ -259,13 +254,12 @@ With the above configuration:
 
 ## Config profiles
 
-Configuration files can contain the definition of one or more *profiles*. A profile is a set of configuration attributes that can be selected during pipeline execution by using the `-profile` command line option.
+Configuration files can define one or more *profiles*. A profile is a set of configuration settings that can be selected during pipeline execution using the `-profile` command line option.
 
-Configuration profiles are defined by using the special scope `profiles`, which group the attributes that belong to the same profile using a common prefix. For example:
+Configuration profiles are defined in the `profiles` scope. For example:
 
 ```groovy
 profiles {
-
     standard {
         process.executor = 'local'
     }
@@ -281,41 +275,47 @@ profiles {
         process.container = 'cbcrg/imagex'
         docker.enabled = true
     }
-
 }
 ```
 
-This configuration defines three different profiles: `standard`, `cluster`, and `cloud`, that each set different process
-configuration strategies depending on the target runtime platform. The `standard` profile is used by default when no profile is specified.
+The above configuration defines three profiles: `standard`, `cluster`, and `cloud`. Each profile provides a different configuration for a given execution environment. The `standard` profile is used by default when no profile is specified.
 
-:::{tip}
-Multiple configuration profiles can be specified by separating the profile names with a comma, for example:
+Configuration profiles can be specified at runtime as a comma-separated list:
 
 ```bash
 nextflow run <your script> -profile standard,cloud
 ```
 
 Config profiles are applied in the order in which they were defined in the config file, regardless of the order they are specified on the command line.
+
+:::{versionadded} 25.02.0-edge
+When using the {ref}`strict config syntax <updating-config-syntax>`, profiles are applied in the order in which they are specified on the command line.
 :::
 
 :::{danger}
-When using the `profiles` feature in your config file, do NOT set attributes in the same scope both inside and outside a `profiles` context. For example:
+When defining a profile in the config file, avoid using both the dot and block syntax for the same scope. For example:
 
 ```groovy
-process.cpus = 1
-
 profiles {
-  foo {
-    process.memory = '2 GB'
-  }
+    foo {
+        process.memory = '2 GB'
+        process {
+            cpus = 2
+        }
+    }
+}
+```
 
-  bar {
-    process.memory = '4 GB'
-  }
+Due to a limitation of the legacy config parser, the first setting will be overwritten by the second:
+
+```console
+$ nextflow config -profile foo
+process {
+   cpus = 2
 }
 ```
 
-In the above example, the `process.cpus` attribute is not correctly applied because the `process` scope is also used in the `foo` and `bar` profiles.
+This limitation can be avoided by using the {ref}`strict config syntax <updating-config-syntax>`.
 :::
 
 ## Workflow handlers

docs/reference/env-vars.md

@@ -12,6 +12,8 @@ The following environment variables control the configuration of the Nextflow ru
 `JAVA_HOME`
 : Defines the path location of the Java VM installation used to run Nextflow.
 
+(nxf-env-vars)=
+
 ## Nextflow settings
 
 `NXF_ANSI_LOG`
@@ -180,6 +182,11 @@ The following environment variables control the configuration of the Nextflow ru
   :::
 : Enable the use of Spack recipes defined by using the {ref}`process-spack` directive. (default: `false`).
 
+`NXF_SYNTAX_PARSER`
+: :::{versionadded} 25.02.0-edge
+  :::
+: Set to `'v2'` to use the {ref}`strict syntax <updating-syntax-page>` for Nextflow config files (default: `'v1'`).
+
 `NXF_TEMP`
 : Directory where temporary files are stored
 

docs/updating-syntax.md

@@ -487,8 +487,14 @@ The process `when` section is deprecated. Use conditional logic, such as an `if`
 
 The process `shell` section is deprecated. Use the `script` block instead. The VS Code extension provides syntax highlighting and error checking to help distinguish between Nextflow variables and Bash variables.
 
+(updating-config-syntax)=
+
 ### Configuration syntax
 
+:::{versionadded} 25.02.0-edge
+The strict config syntax can be enabled in Nextflow by setting `NXF_SYNTAX_PARSER=v2`.
+:::
+
 See {ref}`Configuration <config-syntax>` for a comprehensive description of the configuration language.
 
 Currently, Nextflow parses config files as Groovy scripts, allowing the use of scripting constructs like variables, helper functions, try-catch blocks, and conditional logic for dynamic configuration:
@@ -544,6 +550,6 @@ There are two ways to preserve Groovy code:
  - Move the code to the `lib` directory
  - Create a plugin
 
-Any Groovy code can be moved into the `lib` directory, which supports the full Groovy language. This approach is useful for temporarily preserving some Groovy code until it can be updated later and incorporated into a Nextflow script. See {ref}`<lib-directory>` documentation for more information.
+Any Groovy code can be moved into the `lib` directory, which supports the full Groovy language. This approach is useful for temporarily preserving some Groovy code until it can be updated later and incorporated into a Nextflow script. See {ref}`lib-directory` documentation for more information.
 
 For Groovy code that is complicated or if it depends on third-party libraries, it may be better to create a plugin. Plugins can define custom functions that can be included by Nextflow scripts like a module. Furthermore, plugins can be easily re-used across different pipelines. See {ref}`plugins-dev-page` for more information on how to develop plugins.

modules/nextflow/build.gradle

@@ -20,6 +20,7 @@ compileGroovy {
 dependencies {
     api(project(':nf-commons'))
     api(project(':nf-httpfs'))
+    api 'com.github.nextflow-io.language-server:compiler:main-SNAPSHOT'
     api "org.apache.groovy:groovy:4.0.25"
     api "org.apache.groovy:groovy-nio:4.0.25"
     api "org.apache.groovy:groovy-xml:4.0.25"