Static Typing for Ruby - Shopify

Why Shopify Built Its Own Path to Ruby Typing

Shopify’s core monolith sits at roughly 37,000 Ruby files, 622,000 methods, and more than 2,000,000 calls. With about 400 commits merged daily and 40 deploys a day, the Ruby Infrastructure team started looking for ways to shorten developer feedback loops and add safety to the codebase. Since 2018, their focus has been on one missing feature: static typing.

Ruby typing wasn't new in 2018. Tools like RDL, Steep, and dry-types already existed. What was missing, for Shopify’s specific scale and culture, was a solution that met three requirements:

• Gradual typing: The monolith is evolving constantly. Developers can’t pause feature work to add types to thousands of files. The solution had to allow incremental adoption without blocking progress.
• Speed: With such a large codebase, type checking had to be fast enough to give near-immediate feedback without putting extra pressure on CI.
• Full Ruby support: Shopify uses the full breadth of Ruby, including metaprogramming, overloading, class reopening, and Rails. The tool had to handle all of it, including the hard-to-type parts.

None of the available options satisfied all three needs. Then a meeting with Stripe introduced the team to Sorbet. At the time, Sorbet was closed-source and still in heavy development, but it was built for gradual typing and could analyze about 100,000 lines per second per core. Thanks to Ruby Interface files (RBI), it could also handle metaprogramming constructs. Shopify began its adoption journey in early 2019.

Treating Type Checking as a Product

With a three-person team, Shopify approached Sorbet adoption using its “Get Shit Done” framework. The first steps tested viability on the monolith: a few files were typed to observe benefits and verify developers weren’t impaired, manual RBI files were created for features Sorbet couldn’t yet understand (including Rails constructs), and file coverage was expanded while performance was monitored to confirm the tool scaled.

Once committed, the team needed a roadmap to 100% adoption. That meant understanding how many files required types, what was in them, and which Ruby features were used.

Levels of Strictness

Sorbet’s strictness is set per file via a magic comment or sigil: # typed: LEVEL. The valid levels are:

• ignore: The file isn’t read by Sorbet; no errors are reported.
• false: Only syntax, constant resolution, and sig correctness errors are reported. Method calls aren’t checked.
• true: Type checking begins. All called methods must exist, argument counts must match, and types are checked when signatures exist.
• strict: Every method needs a signature, and all constants and instance variables require explicitly annotated types.
• strong: Untyped variables are disallowed. In practice, it’s not usable for most files—Stripe recommends against it too.

Instrumenting Adoption

To track progress, Shopify built SorbetMetrics, a tool that collects and displays coverage metrics for all internal Sorbet projects. Three core metrics are tracked:

• Sigils: The count of files at each strictness level.
• Calls: How many method calls target methods with signatures.
• Signatures: The total number of typed methods.

SorbetMetrics refreshes daily against the latest monolith version and displays results on an internal dashboard accessible to all developers.

Support, at Monolith Scale

Adoption at scale requires developer support. Shopify began with direct white-glove help: a dedicated Slack channel for teams using Sorbet, aimed at unblocking and getting qualitative feedback. While that didn’t scale as a permanent model, it surfaced the hardest problems and recurring issues, which informed the work queue moving forward. Over time, support migrated to an internal Discourse forum, making answers searchable so developers could self-serve. That step improved scalability as more projects onboarded.

Measuring Developer Sentiment

Beyond unblocking work, the team tracks whether developers actually like Sorbet. Since typing adds some overhead, the benefits need to outweigh it. Surveys run twice a year across all developers, using yes/no and five-point Likert scales to chart opinion shifts. The key findings:

• Sorbet catches more errors on pull requests as adoption grows.
• Signatures improve code comprehension and give developers confidence to ship.
• That confidence translated into a steady increase in positive sentiment toward static typing.
• As developers got comfortable, they pushed for more typed code and more typed projects.
• Complaints about Sorbet syntax faded with exposure.
• IDE integration is the feature developers want most.

The consistent trend is that satisfaction rises as coverage rises. This supports efforts to get the entire monolith to typed: true and maximize signature coverage. In parallel with surveys, the team conducts individual interviews with developers on teams using Sorbet to understand what works and what needs improvement in onboarding workflows.

Where Sorbet Stands Today

Sorbet is currently enforced only on the main monolith, though about 60 internal projects have adopted it voluntarily. In the monolith, every file must be at least typed: false. CI runs Sorbet on every PR and fails builds on type errors, with the team evaluating whether to run type checking before the automated test suite.

As of today, 80% of monolith files have reached typed: true or higher. Roughly half the method calls are fully typed, and half of all methods carry signatures. Full type checking across this codebase takes under 15 seconds on a developer machine.

Usage isn’t limited to the monolith. The number of internal and open-source projects using Sorbet has grown to more than 60 simply through developer preference. Metrics tracking manual runs of the dev tc typecheck command show one clear signal: developers aren’t waiting for CI to catch errors—they’re using Sorbet locally to get feedback sooner.

What Static Typing Delivers on the Monolith

With Sorbet now fully adopted across Shopify’s core monolith and numerous internal projects, the Ruby Infrastructure team is beginning to measure the payoff. That team owns the mandate to keep Ruby fast, scalable, and safe for the company, and static typing has become a central part of that effort — particularly for large, intricate codebases where untyped Ruby tends to get risky.

The decision to back Sorbet wasn’t taken lightly. The team approached static typing as a product in its own right, evaluating it against Shopify’s specific needs rather than adopting it for its own sake. The rollout treated Shopifolk — engineers working in the monolith and beyond — as customers of that product, which shaped both how the tool was introduced and how its success was measured.

Rolling Out Typing as a Product

Treating typing as a product meant thinking carefully about the experience of the engineers who would live with Sorbet every day. That framing influenced the pace of adoption, the tooling built around Sorbet, and the way friction was removed from the workflow. The result is that the benefits now visible on the codebase — and on developer productivity — trace back to those early product decisions.

The work didn’t stop at enabling the type checker. A separate set of efforts focused on building tools to make adoption faster and easier, some of which were open-sourced for the wider Ruby community. Those tools, along with the adoption process itself, are covered in the companion write-up on adopting Sorbet at scale, which also shares preliminary data on whether static typing reduces production errors.