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.

Workflow outputs (out of preview)

Workflow outputs, introduced in Nextflow 24.04 as a preview feature, have been brought out of preview, which means that they can be used without the nextflow.preview.output feature flag.

The syntax has not changed since the third preview, with one exception. Each output declaration in the output block can optionally specify a type annotation:

workflow {
    main:
    ch_samples = // ...

    publish:
    samples = ch_samples
}

output {
    samples: Channel<Map> {
        path '.'
        index {
            path 'samples.csv'
        }
    }
}

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: Value<Path>

    main:
    samples_ch = QUANT( reads, index )

    emit:
    samples: Channel<Path> = samples_ch
}

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

// feature flag required for typed processes
nextflow.preview.types = true

process fastqc {
    input:
    (id, fastq_1, fastq_2): Tuple<String,Path,Path>

    output:
    logs = tuple(id, file('fastqc_logs'))

    script:
    """
    mkdir fastqc_logs
    fastqc -o fastqc_logs -f fastq -q ${fastq_1} ${fastq_2}
    """
}

The following declarations can be annotated with types:

  • Pipeline parameters (the params block)

  • Workflow takes and emits

  • Process inputs and outputs

  • Function parameters and returns

  • Local variables

  • Closure parameters

  • Workflow outputs (the output block)

Type annotations can refer to any of the standard types.

Some types use generic type parameters to work with different data types in a type-safe way. For example:

  • List<E> and Channel<E> use the generic type E to specify the element type in the list or channel

  • Map<K,V> uses the generic types K for the key type and V for the value type in the map

The following examples show types with type parameters:

// List<E> where E is String
def sequences: List<String> = ['ATCG', 'GCTA', 'TTAG']

// List<E> where E is Path  
def fastqs: List<Path> = [file('sample1.fastq'), file('sample2.fastq')]

// Map<K,V> where K is String and V is Integer
def readCounts: Map<String,Integer> = [sample1: 1000, sample2: 1500]

// Channel<E> where E is Path
def ch_bams: Channel<Path> = channel.fromPath('*.bam')

Type annotations can be appended with ? to denote values can be null:

def x_opt: String? = null

In the type system, queue channels are represented as Channel, while value channels are represented as Value. To make the terminology clearer and more concise, queue channels are now called dataflow channels (or simply channels), and value channels are now called dataflow values. See Dataflow for more information.

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.

See Migrating to static types for details.

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 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.

Simpler syntax for 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
    """
}

Dynamic process settings in configuration files must still be specified with closures.

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.

  • The nextflow.config.schema package was renamed to nextflow.config.spec. Plugin developers that define custom configuration scopes will need to update their imports accordingly.

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.