Open-Source Wikis

/

Starship

/

Fun facts

starship/starship

Fun facts

Some bits of trivia from poking around the codebase.

The repository started as JavaScript

The very first commit on Apr 1, 2019 (no, really — that's the actual date, not a joke) landed a Node.js prototype. The Rust rewrite that became today's Starship arrived weeks later. The README's "Inspired By" section still credits both denysdovhan/spaceship-prompt and denysdovhan/robbyrussell-node — a ZSH prompt and a Node-based cross-shell prompt by the same author.

The longest single source file

src/modules/git_status.rs is 2,299 lines — by far the largest module. It deals with merge conflicts, stashed changes, untracked vs ignored, ahead/behind tracking, divergence symbols, WSL fast-paths, submodule handling, and a separate count_stash that reads .git/refs/stash directly because gix didn't initially support it.

The runner-up is src/modules/directory.rs at 1,909 lines — almost all of which is path-shape juggling: home contraction, repo-root contraction, fish-style abbreviation, regex substitution, Windows extended-path stripping, and read-only indicators.

The shell with the most baroque init script

src/init/starship.ps1235 lines of PowerShell. Followed closely by src/init/starship.bash at 153 lines, which contains workarounds for a bash bug (#5159), compatibility hooks for BLE.sh and bash-preexec, and notes citing five different starship pull requests in its top comment.

The shortest: src/init/starship.tcsh at 9 lines.

Renovate is the busiest committer

Of 4,236 total commits, 1,308 (30.9%) come from renovate[bot]. Add dependabot[bot] (322) and the legacy dependabot-preview[bot] (283), and almost half of all commits are automated dependency updates. The most-touched files in any 90-day window are always Cargo.lock and Cargo.toml.

The dprint config has stricter line widths than rustfmt

.rustfmt.toml is short — edition = "2024" and a couple of small overrides — but .dprint.json enforces a Markdown line width and TOML field alignment that has caused at least one PR to be reformatted by CI before being mergeable. The format-workflow GitHub Action fixes formatting drift on demand.

The $schema line in starship.toml

Every starship preset starts with:

"$schema" = 'https://starship.rs/config-schema.json'

That URL is generated by cargo run --features config-schema -- config-schema > .github/config-schema.json from FullConfig via schemars. CI's check_if_config_schema_up_to_date job is what stops a PR from changing a config struct without regenerating the schema.

The Claude Code statusline reads JSON from stdin

Starship has exactly one subcommand that reads anything from stdin: starship statusline claude-code. It parses a JSON payload describing the current Claude Code session (model, context window, cumulative cost) and renders the built-in claude-code profile. The implementation is prompt_with_claude_code in src/print.rs.

The signpath integration

The Windows binaries are signed via SignPath.io. The release CI uploads unsigned MSI/EXE artifacts, then a separate signing step submits them to SignPath through signpath/github-action-submit-signing-request. The signing roles are defined as GitHub teams: starship/astronauts (reviewers) and starship/mission-control (approvers/authors). The README has a "Code Signing Policy" section explaining all of this.

Why gix, and why so picky about features

The Cargo.toml gix declaration includes a comment linking to issue #4251:

gix = { version = "0.83.0", default-features = false, features = ["max-performance-safe", "revision", "zlib-rs", "status", "sha1"] }

Default gix features pulled in heavy dependencies that turned out to slow down prompt rendering. Each feature flag here was added deliberately. There are still a handful of // TODO markers in the git modules waiting for gix to support sparse-index trees, staged-change detection, and reftables.

The os_info upgrade dance

src/configs/os.rs has icons for ~50 operating systems. The Cargo.toml says:

# update os module config and tests when upgrading os_info
os_info = { version = "3.14.0", features = ["schemars"] }

Whenever os_info adds a new OS variant, the module needs a matching symbol — this is one of the few "if you change X, also change Y" couplings in the codebase that's serious enough to deserve a Cargo.toml comment.

Run on April 1st at your own risk

The starship project's first commit was April 1, 2019. The release notes for v1.x releases are full of jokes when they happen on or near April 1. There's no actual April Fool's behavior in the binary today (we checked).

Built by Factory AutoWiki from public repository content. It is a generated preview for codebase exploration, not source-maintained documentation.

Fun facts – Starship wiki | Factory