Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion adr/20251017-typed-processes.md
Original file line number Diff line number Diff line change
Expand Up @@ -245,7 +245,7 @@ Moving topic emissions to a dedicated section allows them to be defined without

## Distinguishing between typed and legacy processes

Typed processes are gated behind the `nextflow.preview.types` feature flag. This flag will be replaced by `nextflow.enable.types` when the feature becomes stable, which will be used to distinguish between typed and legacy processes in the language.
Typed processes are gated behind the `nextflow.enable.types` feature flag, in order to distinguish between typed and legacy processes in the language.

When a script enables this feature flag, its processes are treated as typed processes; otherwise, its processes are treated as legacy processes. This way, typed and legacy processes cannot be mixed in the same script, but they can be used together as long as they are declared in different scripts.

Expand Down
2 changes: 1 addition & 1 deletion adr/20260306-record-types.md
Original file line number Diff line number Diff line change
Expand Up @@ -341,7 +341,7 @@ process FASTQC {

This approach is syntactically more concise, and it re-uses the typed output syntax that was introduced in Nextflow 25.10.

However, with this approach, the same syntax can have different meanings depending on the surrounding context (e.g. presence/absence of the `nextflow.preview.types` feature flag), which can be confusing for both users and agents.
However, with this approach, the same syntax can have different meanings depending on the surrounding context (e.g. presence/absence of the `nextflow.enable.types` feature flag), which can be confusing for both users and agents.

The `record()` approach works "out of the box", and it isn't much more verbose, so we decided that it is sufficient for now.

Expand Down
18 changes: 9 additions & 9 deletions adr/20260310-typed-workflows.md
Original file line number Diff line number Diff line change
Expand Up @@ -85,11 +85,11 @@ Even the pipe (`|`), which is loved by many users, can rarely be used in its ide

Introduce **typed workflows**, which provide a streamlined syntax for workflows that supports static typing.

Typed workflows can be used with the `nextflow.preview.types` feature flag:
Typed workflows can be used with the `nextflow.enable.types` feature flag:

```groovy
// typed workflow
nextflow.preview.types = true
nextflow.enable.types = true

workflow HELLO {
take:
Expand Down Expand Up @@ -131,7 +131,7 @@ The operator library is extended to support static typing and records:

All operators can be used with or without static typing, with some caveats:

- Some operators have stricter semantics when static typing is enabled via `nextflow.preview.types`. These changes are necessary in order to support static typing effectively. They should not affect the majority of existing code.
- Some operators have stricter semantics when static typing is enabled via `nextflow.enable.types`. These changes are necessary in order to support static typing effectively. They should not affect the majority of existing code.

- Some operators are discouraged from use with static typing. While they can still be used, the type checker will not be able to validate them. Users should be encouraged to migrate away from them in favor of the *core operators* that are statically typed.

Expand Down Expand Up @@ -219,7 +219,7 @@ This incremental approach was done in contrast to DSL2, which was a monolithic c

Most of the features for static typing are new concepts that can be used alongside existing code. However, typed processes and typed workflows modify existing concepts (`process` and `workflow` definitions), so they require a feature flag.

The `nextflow.enable.types` feature flag (currently in preview as `nextflow.preview.types`) will be used to distinguish between typed and legacy code, indefinitely. It would only be removed if the support for legacy syntax was removed, which is unlikely since DSL2 has been the standard Nextflow syntax for many years.
The `nextflow.enable.types` feature flag will be used to distinguish between typed and legacy code, indefinitely. It would only be removed if the support for legacy syntax was removed, which is unlikely since DSL2 has been the standard Nextflow syntax for many years.

To help distinguish between typed and legacy workflows, the use of type annotations should be allowed only for typed workflows:

Expand All @@ -239,7 +239,7 @@ workflow greet {

```groovy
// typed workflow
nextflow.preview.types = true
nextflow.enable.types = true

workflow greet {
take:
Expand All @@ -261,7 +261,7 @@ Typed and legacy workflows use different underlying dataflow types:

- **Typed workflows (v2)** use wrapper types: `ChannelImpl` (wraps a `DataflowBroadcast`) and `ValueImpl` (wraps a `DataflowVariable`). These wrappers implement the new operators and integrate with the type system.

While a given script must be entirely typed or entirely legacy (controlled by the `nextflow.preview.types` flag), **typed and legacy workflows can call each other across different scripts**. This interoperability enables incremental migration -- individual scripts can be migrated to static typing without having to update the entire pipeline at once.
While a given script must be entirely typed or entirely legacy (controlled by the `nextflow.enable.types` flag), **typed and legacy workflows can call each other across different scripts**. This interoperability enables incremental migration -- individual scripts can be migrated to static typing without having to update the entire pipeline at once.

### Normalization at call sites

Expand Down Expand Up @@ -293,7 +293,7 @@ workflow LEGACY_ALIGN {

**`typed.nf`**
```groovy
nextflow.preview.types = true
nextflow.enable.types = true

include { LEGACY_ALIGN } from './legacy'

Expand All @@ -312,7 +312,7 @@ workflow {

**`typed.nf`**
```groovy
nextflow.preview.types = true
nextflow.enable.types = true

workflow TYPED_TRIM {
take:
Expand Down Expand Up @@ -371,7 +371,7 @@ workflow LEGACY_QC {

**`typed.nf`**
```groovy
nextflow.preview.types = true
nextflow.enable.types = true

include { LEGACY_QC } from './legacy'

Expand Down
12 changes: 7 additions & 5 deletions docs/migrations/26-04.md
Original file line number Diff line number Diff line change
Expand Up @@ -97,15 +97,15 @@ See {ref}`script-records` for details. See {ref}`migrating-static-types` for mor
<h3>Static typing (preview)</h3>

:::{note}
Typed processes and typed workflows require the `nextflow.preview.types` feature flag to be enabled in every script that uses them.
Typed processes and typed workflows require the `nextflow.enable.types` feature flag to be enabled in every script that uses them.
:::

Nextflow 26.04 brings full support for static typing with {ref}`typed processes <process-typed-page>` and {ref}`typed workflows <workflow-typed-page>`.

Typed processes can now declare record inputs and outputs:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

process FASTQC {
input:
Expand All @@ -129,7 +129,7 @@ process FASTQC {
Typed workflows can declare typed inputs and outputs, and provide first-class support for static typing in dataflow logic:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

workflow RNASEQ {
take:
Expand Down Expand Up @@ -158,6 +158,10 @@ Several operators have been extended to support static typing and records:

Breaking changes from the {ref}`first preview <static-typing-first-preview>`:

- The `nextflow.preview.types` feature flag has been replaced with `nextflow.enable.types`.

- The `nextflow.enable.types` feature flag must be enabled in order to use type annotations in workflow takes/emits.

- The syntax for process tuple inputs has been updated:

```nextflow
Expand All @@ -172,8 +176,6 @@ Breaking changes from the {ref}`first preview <static-typing-first-preview>`:

- The method signature for the `stageAs` directive was changed from `(filePattern, value)` to `(value, filePattern)`.

- The `nextflow.preview.types` feature flag must be enabled in order to use type annotations in workflow takes/emits.

See {ref}`migrating-static-types` for more information about migrating to static typing. See {ref}`migrating-static-types-operators` for best practices on using operators with static typing.

## Enhancements
Expand Down
4 changes: 2 additions & 2 deletions docs/process-typed.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ Typed processes are a preview feature. The syntax and behavior may change in fut
Typed processes use a new syntax for inputs and outputs that supports static typing.

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

process hello {
input:
Expand All @@ -36,7 +36,7 @@ To use this feature:
export NXF_SYNTAX_PARSER=v2
```

2. Set `nextflow.preview.types = true` in every script that uses typed processes.
2. Set `nextflow.enable.types = true` in every script that uses typed processes.

See {ref}`syntax-process-typed` for the complete syntax reference and {ref}`migrating-static-types` to migrate existing code to static typing.

Expand Down
2 changes: 1 addition & 1 deletion docs/reference/channel.md
Original file line number Diff line number Diff line change
Expand Up @@ -354,7 +354,7 @@ A *topic channel* is a channel that can receive values from many sources *implic
A typed process can emit values to a topic using the `topic:` section:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

process hello {
topic:
Expand Down
28 changes: 4 additions & 24 deletions docs/reference/feature-flags.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,10 @@

# Feature flags

Feature flags enable experimental or other opt-in features. They must be specified in the pipeline script.
Feature flags enable opt-in features. They must be specified in the pipeline script.

:::{warning}
Feature flags with the `nextflow.preview` prefix can cause pipelines run with newer versions of Nextflow to fail due to breaking changes. Always consult the {ref}`migration notes <migrations-page>` before updating to a new Nextflow version.
Feature flags marked as *preview* can cause pipelines run with newer versions of Nextflow to fail due to breaking changes. Always consult the {ref}`migration notes <migrations-page>` before updating to a new Nextflow version.
:::

`nextflow.enable.configProcessNamesValidation`
Expand Down Expand Up @@ -49,28 +49,8 @@ Feature flags with the `nextflow.preview` prefix can cause pipelines run with ne

- Nextflow will fail if multiple functions and/or processes with the same name are defined in a module script

`nextflow.preview.output`
: :::{versionadded} 24.04.0
:::
: :::{deprecated} 25.10.0
This feature flag is no longer supported. Workflow outputs are out of preview.
:::
: When `true`, enables the use of {ref}`workflow outputs <workflow-output-def>`.

`nextflow.preview.recursion`
: *Preview feature: the syntax and behavior may change in future releases.*
: When `true`, enables {ref}`process and workflow recursion <workflow-recursion>`.

`nextflow.preview.topic`
: :::{versionadded} 24.04.0
:::
: :::{deprecated} 25.04.0
This feature flag is no longer supported. Topic channels are out of preview.
:::
: When `true`, enables the use of {ref}`topic channels <channel-topic>`.

`nextflow.preview.types`
: :::{versionadded} 25.10.0
`nextflow.enable.types`
: :::{versionadded} 26.04.0
:::
: *Preview feature: the syntax and behavior may change in future releases.*
: When `true`, enables the use of {ref}`typed processes <process-typed-page>` and {ref}`typed workflows <workflow-typed-page>`. Must be enabled in every script that uses typed processes/workflows. Legacy processes/workflows cannot be defined in scripts with this flag enabled.
6 changes: 3 additions & 3 deletions docs/reference/operator.md
Original file line number Diff line number Diff line change
Expand Up @@ -208,7 +208,7 @@ The `collect` operator behaves differently from `toList` in the following ways:
- `collect` flattens collected values whereas `toList` does not.

:::{note}
When static typing is enabled via `nextflow.preview.types`, `collect` behaves the same way as `toList`.
When static typing is enabled via `nextflow.enable.types`, `collect` behaves the same way as `toList`.
:::

## collectFile
Expand Down Expand Up @@ -527,7 +527,7 @@ When the mapping function returns a map, each key-value pair in the map is emitt
```

:::{note}
When static typing is enabled via `nextflow.preview.types`, `flatMap` does not flatten maps or tuples.
When static typing is enabled via `nextflow.enable.types`, `flatMap` does not flatten maps or tuples.
:::

(operator-flatten)=
Expand Down Expand Up @@ -728,7 +728,7 @@ The `map` operator applies a *mapping function* to each item from a source chann
```

:::{note}
By default, null values are not emitted by `map`. When static typing is enabled via `nextflow.preview.types`, null values are emitted.
By default, null values are not emitted by `map`. When static typing is enabled via `nextflow.enable.types`, null values are emitted.
:::

(operator-max)=
Expand Down
2 changes: 1 addition & 1 deletion docs/reference/process.md
Original file line number Diff line number Diff line change
Expand Up @@ -63,7 +63,7 @@ The following task properties are defined in the process body:
:::

:::{note}
Typed processes require the `nextflow.preview.types` feature flag to be enabled in every script that uses them. The syntax and behavior may change in future releases.
Typed processes require the `nextflow.enable.types` feature flag to be enabled in every script that uses them.
:::

### Stage directives
Expand Down
4 changes: 2 additions & 2 deletions docs/reference/syntax.md
Original file line number Diff line number Diff line change
Expand Up @@ -205,7 +205,7 @@ Entry workflow definitions are ignored when a script is included as a module. Th
A typed workflow is a workflow that uses static typing for inputs and outputs:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

workflow greet {
take:
Expand Down Expand Up @@ -303,7 +303,7 @@ See {ref}`process-page` for more information on the semantics of each process se
A typed process is a process that uses static typing for inputs and outputs:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

process greet {
input:
Expand Down
4 changes: 2 additions & 2 deletions docs/tutorials/static-types-operators.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ All operators can be used with or without static typing (i.e. {ref}`typed workfl

## Core operators

The {ref}`core operators <operator-typed-page>` are recommended for use with static typing. When static typing is enabled (via `nextflow.preview.types`), some of these operators have stricter semantics which may require minor changes to pipeline code. These cases are described below.
The {ref}`core operators <operator-typed-page>` are recommended for use with static typing. When static typing is enabled (via `nextflow.enable.types`), some of these operators have stricter semantics which may require minor changes to pipeline code. These cases are described below.

### collect

Expand Down Expand Up @@ -264,7 +264,7 @@ You can compose these functions and operators as needed to achieve the desired f
For example:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

process COLLECT_FILE {
input:
Expand Down
20 changes: 10 additions & 10 deletions docs/tutorials/static-types.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ See {ref}`devenv-page` for instructions on how to setup VS Code and the Nextflow

When using static typing, the language server can check your code for type-related errors. For example, it can validate that a channel of records has all the required fields when it is passed as input to a process.

The language server performs type checking on every script that enables the `nextflow.preview.types` feature flag.
The language server performs type checking on every script that enables the `nextflow.enable.types` feature flag.

### Automatic migration

Expand Down Expand Up @@ -212,7 +212,7 @@ Collection-type params can also be loaded from JSON and YAML samplesheets. See {
See {ref}`process-typed-page` for an overview of typed processes.

:::{note}
You must enable the `nextflow.preview.types` feature flag in each script that uses typed processes.
You must enable the `nextflow.enable.types` feature flag in each script that uses typed processes.
:::

<h4>FASTQC</h4>
Expand Down Expand Up @@ -240,7 +240,7 @@ process FASTQC {
To migrate the `FASTQC` process, rewrite the inputs and outputs as follows:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

process FASTQC {
tag id
Expand Down Expand Up @@ -304,7 +304,7 @@ process QUANT {
To migrate the `QUANT` process, rewrite the inputs and outputs as follows:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

process QUANT {
tag id
Expand Down Expand Up @@ -364,7 +364,7 @@ process MULTIQC {
To migrate this process, rewrite the inputs and outputs as follows:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

process MULTIQC {
// ...
Expand Down Expand Up @@ -406,7 +406,7 @@ Once you migrate every process called by a workflow to static typing, you can mi
See {ref}`workflow-typed-page` for an overview of typed workflows.

:::{note}
You must enable the `nextflow.preview.types` feature flag in each script that uses typed workflows.
You must enable the `nextflow.enable.types` feature flag in each script that uses typed workflows.
:::

<h4>RNASEQ</h4>
Expand Down Expand Up @@ -451,7 +451,7 @@ You can determine the type of each input as follows:
Specify the workflow input types as follows:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

workflow RNASEQ {
take:
Expand Down Expand Up @@ -491,7 +491,7 @@ These channels are emitted as the outputs of `RNASEQ`. However, with records it
Use the `join` operator to join `fastqc_ch` and `quant_ch` by sample ID:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

workflow RNASEQ {
take:
Expand Down Expand Up @@ -525,7 +525,7 @@ record AlignedSample {
Update the workflow to emit `samples_ch` with the new record type:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

workflow RNASEQ {
take:
Expand Down Expand Up @@ -562,7 +562,7 @@ workflow {
Rewrite this workflow based on the updated params, processes, and subworkflows:

```nextflow
nextflow.preview.types = true
nextflow.enable.types = true

workflow {
read_pairs_ch = channel.fromList(params.reads)
Expand Down
Loading
Loading