We’re live in beta! Here are our next steps
Last week, we at gem.coop announced support for namespaces that you can publish to and use namespaced gems in Bundler today. Our original post outlines how namespaces improve package security, but in this post we’ll go through how to use them and how Bundler handles namespaced gems.
From the moment RubyGems was first created in 2004, Ruby Central provided governance without claiming ownership, to support the Ruby community. Providing governance meant creating processes to provide stability and predictability. Avoiding ownership meant allowing the community to contribute, to the point where unpaid volunteers created and controlled the entirety of RubyGems.org for many years.
Last year, Ruby Central flipped that successful formula on its head. They now claim ownership of both Bundler and RubyGems, but refuse to provide governance. Ruby Central now claims sole control over all code and decisions, despite paying for only a few percent of the work required to create and sustain the projects across 22 years. Instead of providing stable and predictable processes, Ruby Central suddenly hijacked the Bundler and RubyGems codebases away from the existing maintainers, shut out the community, and started issuing the threats to sue.
Temporal: The 9-Year Journey to Fix Time in JavaScript
JavaScript's Date object has been a source of bugs for three decades. Temporal, which just reached Stage 4, is a modern replacement with immutable types, first-class time zone and calendar support, and nanosecond precision. This is the story of how Bloomberg, Igalia, and the TC39 community spent nine years turning an idea into a shipping standard.
Nitro v3 is now available as a public beta — a ground-up evolution of the server framework, built around web standards, Rolldown, Vite v8, and the same deploy-anywhere promise.
We locate web content using special addresses called URLs. We are all familiar with addresses like https://google.com. Sometimes, URLs can get long and they can become difficult to read. Thus, we might be tempted to format them like so in HTML using newline and tab characters, like so: a href="https://lemire.me/blog/2026/02/21/ how-fast-do-browsers-correct-utf-16-strings/"my blog post/a It will … Continue reading You can use newline characters in URLs
Seven Years to TypeScript: Migrating 11,000 Files at Patreon
Between 2019 and 2026, we migrated Patreon’s entire frontend codebase from JavaScript to TypeScript, spanning 11,000 files and over 1 million lines of code. Our initial approach was organic. We enabled TypeScript support and let teams adopt it voluntarily. But by 2022, we realized voluntary adoption alone wouldn't get us there. We needed infrastructure, tooling, and eventually AI-powered automation to complete the journey. What began as a grassroots experiment evolved into one of our most ambitious infrastructure projects. Here's how we approached the migration and what we learned from seven years of incremental progress. Breaking down the journey Our seven-year migration evolved across three distinct eras, each with its own strategy and tooling. The chart below shows our migration trajectory. Notice the slow organic growth through 2022, steady infrastructure-driven progress through 2024, and dramatic acceleration in 2025 as AI tools matured. Era 1: Grassroots (2019-2022) In early 2019, a few adventurous frontend engineers started writing new features in TypeScript. There was no official mandate and no migration plan. We added TypeScript support to our build tooling with a permissive configuration: What went right Low friction adoption. Engineers could experiment with TypeScript without fear of breaking things. If they liked it, they could keep using it. But if they didn't, they could stick with JavaScript. Viral spread. When one engineer on a team adopted TypeScript and others saw the benefits (better autocomplete, catching bugs at compile time, self-documenting interfaces) they wanted it too. TypeScript spread organically across teams. What went wrong TypeScript builds weren't passing. We didn't run type checking in CI. If you ran tsc on the master branch, you'd get hundreds of errors. Truthfully, TypeScript was more like an opinionated autocomplete than a real type system. No shared patterns or foundations. We had no shared types for core concepts like creators, posts and memberships. Every file that touched these concepts either defined its own ad-hoc types (often incorrectly) or didn't add types at all. Growing type debt. As more code was written in TypeScript, the lack of foundational types became more painful. You couldn't properly type a component that used the API since the API responses were typed with any . And you couldn't properly type a page component since our routing library had no type information about which routes existed By late 2021, less than 10% of our codebase was in TypeScript files and even less was meaningfully typed. We had syntax but lacked safety. Era 2: First-Class TypeScript Support (2022-2024) In early 2022, we formed the frontend platform team at Patreon. Improving developer experience was a core part of the team’s charter. Motivation for better TypeScript support TypeScript foundations became a priority for developer experience because: Null JavaScript reference errors were a consistent source of production incidents. Engineers hesitated to refactor shared code, fearing unknown breakage without typed contracts. New team members spent weeks building mental models of data structures that should have been self-documenting. Since we lost several engineering hours per week due to type-related issues, the business use case was straightforward too. Building the foundation We decided that we would treat TypeScript as first-class. This meant: Type checking must pass on master. So we made tsc a required CI check. Foundational types must exist. So we created shared types for core domain concepts. However, we couldn't freeze feature development for a big-bang migration. We needed an approach that let us migrate incrementally while maintaining continuous feature velocity. We ship major creator features monthly so any migration strategy that blocked product work was a non-starter. We took a pragmatic approach and methodically added types for: API objects. Core domain models (e.g. user, creator, membership, post) were passed to client consumers in a type-safe way. Routing system. Route definitions and navigation helpers were typed so the compiler knew which routes existed and what parameters they accepted Analytics. Typed wrappers around our analytics systems were implemented so event names and properties were checked at compile time Each of these was a multi-week project. But once done, they provided type information that propagated throughout the codebase. As a result of well-typed foundational infrastructure, we shipped fewer incidents in areas where types were comprehensive, and code reviews felt safer when reviewers could rely on type information to understand data flow and contracts. The remaining problem By the end of 2024, we had excellent TypeScript infrastructure and adoption on new code. But 2000+ old files were still JavaScript because of how tedious it was to convert them. The typical process was: Rename .js to .ts Add types to function parameters Add types to function return values Add types to local variables Fix all the type errors (often dozens per file) Test that nothing broke This effort was exacerbated by: Legacy patterns from 2013. Our codebase predated modern React conventions, with untyped global state from before our Next.js migration, stage-0 decorator syntax TypeScript didn't support, and deeply nested Higher-Order Components (HOCs) passing props through layers. Lost institutional knowledge. Much of our oldest code was written by engineers who had left years ago. Entire subsystems lacked anyone who fully understood their intended behavior. For a complex file, migrating from JavaScript to TypeScript could take 2-4 hours. At that rate, migrating 2000 files would take multiple engineer-years! It was never going to happen through voluntary effort by product teams since migrating legacy JavaScript files provided collective benefit but individual cost. No engineer could spend weeks migrating old code when they had competing priorities and new features to build. The incentives didn't align so we needed to move away from manual migration. Era 3: The Concerted Migration (2025) In 2025, the frontend platform team committed to clearing the remaining JavaScript files and finally achieving end-to-end type safety. To finish the swing, we assembled a task force and adopted a multi-pronged strategy that evolved with AI capabilities. Phase 1: The ts-migrate foundation We started with proven tooling. Airbnb had open-sourced ts-migrate , a codemod tool specifically designed for TypeScript migrations. It wasn't perfect, but it was battle-tested on codebases similar to ours. ts-migrate works by: Renaming .js → .ts files Adding type annotations where it can infer them and $TSFixMe (alias for any ) where it can't. Converting React PropTypes to TypeScript interfaces Adding // @ts-expect-error comments on lines with errors The output isn't beautiful, but it compiles. Here's what a migration looked like: This wasn’t fancy but it allowed us to migrate hundreds of simple function components to TypeScript. However, static analysis struggled with: Redux patterns Higher-order components Files with heavy use of this context Dynamically generated code Legacy decorator syntax These files either failed to migrate or ended up so littered with any that they were barely better than JavaScript. Phase 2: AI-powered codemods As GPT-4 and Claude matured, we realized we could use AI to write codemods that handled patterns ts-migrate couldn't. This was more sophisticated than simple AST transformations as we could leverage semantic understanding. Our process for AI-generated codemods involved 8 steps: Identify a common pattern that needs migration (e.g. all files using decorator X) Provide AI with 5-10 example files showing the pattern Ask AI to write a codemod using jscodeshift Test the codemod on 50 files manually Review the output, tweak the prompt, regenerate Once confident, run on all matching files Create a PR, let CI and tests validate Ship if tests pass This let us tackle categories of files that would have been impossible with pure static analysis. Example 1: React Classes to TypeScript Many of our legacy React components used custom context for i18n. We wrote a codemod to automatically convert hundreds of these to TypeScript: Example 2: Legacy decorator migration Our codebase used an old decorator syntax that TypeScript poorly supported and had to be converted to HOC wrapper calls. To address this, we wrote a codemod with AI that successfully migrated all 500+ decorator usages in our codebase: Phase 3: Localized AI fixes By this point, we'd migrated most of the "easy" files. What remained were complex files with gnarly type errors. These needed human-level understanding to fix properly. But we noticed something interesting: many of these files had errors that were highly localized. A test file might have 15 type errors, but they were all in isolated test cases that didn't interact with each other. So, we developed a localized fix strategy: For files with localized errors, we'd add @ts-expect-error comments with the specific error messages: We'd then use AI to fix each error individually by: Uploading the file with the error comment Asking AI to fix just the error in the file Running type check If it passed, keeping the change If it failed, trying again or moving on We'd batch these fixes, processing 50-100 files per day. This approach worked well for low-risk areas such as tests and internal tools where the blast radius was limited. In early 2025, AI tooling didn’t feel production-ready, so we kept it away from user-facing code. Phase 4: Advanced AI workflows As the second half of 2025 rolled around, AI workflows became sophisticated enough that we felt confident using them on user facing code. This is where things really accelerated. The breakthrough was realizing we could use AI as an orchestrator that delegates to specialized subagents: Orchestrator
A few weeks ago, I posted lamenting the current state of web dependencies. Turns out that external import maps — the lack of which I had identified as a core limitation — can be emulated today!
Thoughts on OpenAI acquiring Astral and uv/ruff/ty
The big news this morning: Astral to join OpenAI (on the Astral blog) and OpenAI to acquire Astral (the OpenAI announcement). Astral are the company behind uv, ruff, and ty—three …
