Nushell 0.114 Keeps Structured Shell Pipelines Moving Toward 1.0

Nushell published version 0.114.0 on July 4, 2026, continuing its pre-1.0 release line rather than declaring the compatibility milestone prematurely. The numbering matters: Nushell’s project still presents 1.0 as a destination, not an already completed release.

The pipeline carries values, not only lines

Traditional shells connect byte streams. Nushell commands instead commonly exchange typed values organized into records, lists, and tables. A listing can therefore remain structured while later stages select columns, filter rows, sort numeric fields, and render the final result.

ls | where size > 10mb | sort-by size | select name size modified

This does not abolish text: external programs still consume and produce bytes, and Nushell includes parsers and serializers to cross that boundary. The distinction is that built-in pipeline stages can retain types rather than forcing every intermediate step through ad hoc text parsing.

Why a long pre-1.0 period can be responsible

Shell syntax, command names, plugin interfaces, and serialized data formats become expensive to change after users build dotfiles and automation around them. A pre-1.0 label allows the project to continue correcting those interfaces while communicating that compatibility can still move between releases.

That also makes release notes essential operational reading. Users should test scripts against a pinned Nushell version, review breaking changes before upgrades, and avoid treating examples for one 0.x release as a permanent language contract.

What this release represents

Version 0.114 is another incremental delivery in a project that describes itself as “a new type of shell.” Its durable contribution is the experiment itself: applying data-frame-like interaction and a purpose-built language to jobs that conventional shells approach as text transformations.

Whether Nushell replaces a POSIX shell for a given user is a separate decision. It can be an effective interactive data tool while Bash, Dash, or another POSIX-oriented shell remains the portability target for system scripts.

Where the project’s structured-data premise actually came from

The project’s August 2019 introduction describes Nushell as drawing from Unix pipelines, PowerShell’s structured-data approach, functional programming, and systems programming. It credits Sophia Turner, Yehuda Katz, and Andrés Robalino on that announcement. This is useful context for the data-oriented design, but the release itself is the authority for what changed in version 0.114.0.

Why the destination matters more than the version number itself

In its 2023 roadmap, the Nushell team described 1.0 as a stability promise: a supported language intended to be reliable and backward-compatible. The post also explicitly said that full stability was not yet promised and that breaking changes could continue while the core feature set was being clarified. That is a historical statement of direction, not a substitute for the release notes of any particular version.

A release with changes that affect both scripts and interactive use

The headline features are not only conveniences. The 0.114.0 announcement says the parser infers pipeline output types more precisely, represents optional values more accurately, and improves type information for pipeline bindings. It also changes experimental runtime annotation enforcement from opt-in to opt-out. Scripts that relied on old inference or assignments that previously passed could now produce earlier or clearer failures. This is valuable feedback, but it makes a version-pinned test run important before upgrading unattended jobs.

The release also changed module behavior: importing a module no longer implicitly imports its exported submodules. A module author who depended on the former implicit behavior must explicitly re-export or import the nested module. This is a concrete compatibility change for Nushell modules and dotfiles, even if ordinary one-line pipelines need no changes.

End-of-options parsing and script stages

The POSIX-style double-dash delimiter provides a direct way to pass a leading-dash positional value after options. The upstream release example defines a command with a flag and then calls it with a name beginning with a dash:

def greet [--upper, name] {
    if $upper { $name | str uppercase } else { $name }
}
greet -- -Alice

The delimiter is useful when building wrappers around filenames, branch names, or other user-provided strings that can begin with a hyphen. It is not a universal change to every external utility: the called command still defines its own arguments, and wrapper code should test the command-specific parser behavior.

The new run command lets a Nushell script act as a pipeline stage. The release notes show data piped into a script and then into another built-in command. Nushell scripts can be simple transforms or expose a main entry point, and the script runs in an isolated scope so its local definitions do not silently become the caller’s session state. This enables reusable pipeline components, but argument handling, input type, output type, and failure behavior should be documented just as they would be for a conventional command-line program.

Semantic versions as values

Version strings are not correctly ordered by ordinary lexical sorting: for example, a string comparison can put 1.10.0 before 1.2.0. Nushell 0.114.0 adds a SemVer value and commands to parse, convert, sort, and bump versions. The official example is:

'1.2.3-alpha.1' | into semver | semver bump release

Typed versions help avoid ad hoc substring manipulation, but a version parser does not decide an application’s release policy. Scripts still need to choose whether to accept prereleases, how to handle build metadata, and what “release” means for their publishing workflow. Validate the output against the package registry or deployment system that consumes it.

Tables are convenient, but not a universal byte protocol

Nushell’s built-in commands can pass structured records and tables through a pipeline, which makes filtering and sorting by named fields straightforward. For example, a file listing can be narrowed and sorted while the size and timestamp remain typed values rather than display columns. External programs, however, still generally speak byte streams. Nushell provides commands to parse and serialize formats, but parsing a human-oriented output column is not automatically safe: spacing, localization, filenames, and tool versions can change the text.

For durable automation, prefer a documented structured output option from the external program, then parse the declared format. Keep terminal display as a final rendering step rather than an intermediate data contract. This distinction lets Nushell’s typed pipeline help where it has information without pretending that every Unix command has become a typed API.

Upgrade guidance and present-day context

Version 0.114.1 followed on July 11, 2026. Its patch announcement specifically says it fixes issues found after runtime annotations became opt-out, including improvements to type checks and error reporting. The official release notes are therefore essential for systems that moved to 0.114.0 immediately; use the patch release or a later tested version rather than assuming the initial release is the final word.

As of this article’s update date, the Nushell project had published 0.116.0 on September 26, 2026. That means 0.114 is a historical release being discussed here, not a recommendation to install it as the current version. The later release also contains its own breaking change to custom completers, demonstrating why the version number and upgrade notes should accompany any reproduction report.

For controlled deployments, record the exact Nushell version, platform, plugin set, and configuration revision. Test startup, scripts, imported modules, and pipelines with representative data; compare exit status and serialized output; then upgrade a small canary before changing fleet-wide automation. A pre-1.0 label communicates that stability is still an explicit project goal rather than a guarantee already in force. It does not mean every upgrade breaks scripts, and it does not excuse skipping change review.

Related:

Sources: