Rename nextflow.preview.types flag to nextflow.enable.types

Renames the static-typing feature flag and associated field
(`previewTypes` → `enableTypes`) across sources, tests, integration
`.nf` scripts, and documentation. The existing `log.warn` in
`BaseScript.enableTyping()` still clarifies that static typing remains
a preview feature.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@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. 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.
 
 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 (currently in preview as `nextflow.enable.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.
 
 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/25-10.md

@@ -100,7 +100,7 @@ def isSraId(id: String) -> Boolean {
 }
 
 // feature flag required for typed processes
-nextflow.preview.types = true
+nextflow.enable.types = true
 
 process fastqc {
     input:

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:
@@ -172,7 +172,7 @@ 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.
+- The `nextflow.enable.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.
 

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

@@ -69,7 +69,7 @@ Feature flags with the `nextflow.preview` prefix can cause pipelines run with ne
   :::
 : When `true`, enables the use of {ref}`topic channels <channel-topic>`.
 
-`nextflow.preview.types`
+`nextflow.enable.types`
 : :::{versionadded} 25.10.0
   :::
 : *Preview feature: the syntax and behavior may change in future releases.*

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. The syntax and behavior may change in future releases.
 :::
 
 ### Stage directives