Rename nextflow.preview.types feature flag to nextflow.enable.types (#7067)

Co-authored-by: Ben Sherman <bentshermann@gmail.com>

Author: pditommaso

adr/20251017-typed-processes.md

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

adr/20260306-record-types.md

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

adr/20260310-typed-workflows.md

@@ -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:
@@ -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.
 
@@ -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:
 
@@ -239,7 +239,7 @@ workflow greet {
 
 ```groovy
 // typed workflow
-nextflow.preview.types = true
+nextflow.enable.types = true
 
 workflow greet {
     take:
@@ -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
 
@@ -293,7 +293,7 @@ workflow LEGACY_ALIGN {
 
 **`typed.nf`**
 ```groovy
-nextflow.preview.types = true
+nextflow.enable.types = true
 
 include { LEGACY_ALIGN } from './legacy'
 
@@ -312,7 +312,7 @@ workflow {
 
 **`typed.nf`**
 ```groovy
-nextflow.preview.types = true
+nextflow.enable.types = true
 
 workflow TYPED_TRIM {
     take:
@@ -371,7 +371,7 @@ workflow LEGACY_QC {
 
 **`typed.nf`**
 ```groovy
-nextflow.preview.types = true
+nextflow.enable.types = true
 
 include { LEGACY_QC } from './legacy'
 

docs/migrations/26-04.md

@@ -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:
@@ -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:
@@ -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
@@ -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

docs/process-typed.md

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

docs/reference/channel.md

@@ -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:

docs/reference/feature-flags.md

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

docs/reference/operator.md

@@ -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
@@ -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)=
@@ -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)=

docs/reference/process.md

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

docs/reference/syntax.md

@@ -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:
@@ -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: