Migrating to 25.10 (preview)

This page summarizes the upcoming changes in Nextflow 25.10, which will be released in October 2025.

Note

This page is a work in progress and will be updated as features are finalized. It should not be considered complete until the 25.10 release.

New features

Workflow params

The params block is a new way to declare pipeline parameters in a Nextflow script:

params {
  // Path to input data.
  input: Path

  // Whether to save intermediate files.
  save_intermeds: Boolean = false
}

workflow {
  println "params.input = ${params.input}"
  println "params.save_intermeds = ${params.save_intermeds}"
}

This syntax allows you to declare all parameters in one place with explicit type annotations, and it allows Nextflow to validate parameters at runtime.

See Parameters for details.

Type annotations

Type annotations are a way to denote the type of a variable. They help document and validate pipeline code.

workflow RNASEQ {
  take:
  reads: Channel<Path>
  index: Channel<Path>

  main:
  samples_ch = QUANT( reads.combine(index) )

  emit:
  samples: Channel<Path> = samples_ch
}

def isSraId(id: String) -> Boolean {
  return id.startsWith('SRA')
}

The following declarations can be annotated with types:

  • Pipeline parameters (the params block)

  • Workflow takes and emits

  • Function parameters and returns

  • Local variables

  • Closure parameters

  • Workflow outputs (the output block)

Type annotations can refer to any of the standard types.

Type annotations can be appended with ? to denote that the value can be null:

def x_opt: String? = null

Note

Nextflow supports Groovy-style type annotations using the <type> <name> syntax, but this approach is deprecated in strict syntax. While Groovy-style annotations remain valid for functions and local variables, the language server and nextflow lint automatically convert them to Nextflow-style annotations during code formatting.

Enhancements

Nextflow plugin registry

Nextflow now uses the Nextflow plugin registry to download plugins in a more efficient and scalable manner.

The legacy plugin index can still be used by setting the NXF_PLUGINS_REGISTRY_URL environment variable:

export NXF_PLUGINS_REGISTRY_URL="https://raw.githubusercontent.com/nextflow-io/plugins/main/plugins.json"

Note

Plugin developers will not be able to submit PRs to the legacy plugin index once the plugin registry is generally available. Plugins should be updated to publish to the Nextflow plugin registry using the Nextflow Gradle plugin instead. See The Nextflow plugin registry for details.

New syntax for workflow handlers

The workflow onComplete and onError handlers were previously defined by calling workflow.onComplete and workflow.onError in the pipeline script. You can now define handlers as onComplete and onError sections in an entry workflow:

workflow {
    main:
    // ...

    onComplete:
    println "workflow complete"

    onError:
    println "error: ${workflow.errorMessage}"
}

This syntax is simpler and easier to use with the strict syntax. See Workflow handlers for details.

Improved handling of dynamic directives

The strict syntax allows dynamic process directives to be specified without a closure:

process hello {
    queue (entries > 100 ? 'long' : 'short')

    input:
    tuple val(entries), path('data.txt')

    script:
    """
    your_command --here
    """
}

See Dynamic directives for details.

Configurable date formatting

You can now customize the date and time format used in notifications, reports, and console output using the NXF_DATE_FORMAT environment variable:

# Default format
# e.g., 11-Aug-2016 09:40:20

# Use ISO format with timezone
export NXF_DATE_FORMAT="iso"
# e.g., 2016-08-11T09:40:20+02:00

# Use custom format
export NXF_DATE_FORMAT="yyyy-MM-dd HH:mm"
# e.g., 2016-08-11 09:40

This feature addresses previous inconsistencies in timestamp representations.

Breaking changes

  • The AWS Java SDK used by Nextflow was upgraded from v1 to v2, which introduced some breaking changes to the aws.client config options. See the guide for details.

Deprecations

  • The legacy type detection of CLI parameters is disabled when using the strict syntax (NXF_SYNTAX_PARSER=v2). Legacy parameters in the strict syntax should not rely on legacy type detection. Alternatively, use the new params block to convert CLI parameters based on their type annotations. Legacy type detection can be disabled globally by setting the environment variable NXF_DISABLE_PARAMS_TYPE_DETECTION=true.

  • The use of workflow handlers in the configuration file has been deprecated. You should define workflow handlers in the pipeline script or a plugin instead. See Workflow handlers for details.