Porting JS to TypeScript with Claude Code

By default Claude Code struggles to port JavaScript to TypeScript. Often the types it generates are filled with usages of any or inline cast like x as unknown as { bleh(): void }. In the worst cases it abandons entire files and inserts @ts-nocheck disabling typechecking for those files altogether.

The problem is Claude Code prioritizes a passing typecheck after every single edit. It treats a successful tsc run as a strict requirement; if a cast is the quickest way to resolve an immediate error, it will use one. Each edit is locally successful but the overall result is poor. This leads to a codebase cluttered with any and as unknown as.

This is the wrong approach. Effective typing requires knowledge about the shared architecture of a program not just reacting to typecheck errors from tsc.

Two Pass Workflow

The solution is straightforward: port the codebase in two passes and prevent Claude from running tsc during the first pass. By removing the immediate requirement for a successful typecheck we force Claude Code to focus on designing types from its own reasoning rather then simply silencing errors.

  • Pass 1: Add types: Claude is forced to add type annotations without invoking tsc, forcing it to build the types entirely from its own reasoning and the context window it creates by scanning the codebase.
  • Pass 1.5: Coherence Review: Claude reviews the ported files for global type coherency. Typechecking is still disabling.
  • Pass 2: Resolving Errors (Typechecker Enabled). Only now does Claude run tsc and resolve (any remaining) type errors.

Hard Limits

It’s also useful to set a few hard limits for claude code:

  • No use of unknown or any during phase 1 and 1.5 at all.
  • any limited to X usages across the entire codebase for pass 2.
  • Enable strictNullChecks from the beginning.

Establish a Testing Baseline

It’s important to make sure the old JS codebase has adequate unit tests. You can have Claude Code generate these for you, e.g.: First, review the core logic in [target file/directory] and generate a comprehensive suite of unit tests for the existing JavaScript. Ensure the tests pass. Once established, use the js-to-ts-port skill to port the code to TypeScript, using the test suite to verify the logic remains intact.


I have packaged this methodology as a Claude Code skill: js-to-ts-port.

CAD Curve Basics

A boundary representation (BREP) is a data structure used to represent all things topological: 3D meshes, 2d vector curves, volumes, etc. This post is about what makes a good boundary representation for CAD, tailored to support complex curves in a mathematically intutive (and correct) way.

What Is A Curve

What is a curve? A curve is a multidimensional function that is parameterized with one variable.

fx(t),fy(t)fx(t), fy(t)
Continue reading CAD Curve Basics

Simple GPU Vector Graphics With Spatial Trees

Rendering 2D vector graphics on the GPU is a notoriously vexing problem. The most popular publicly available methods are either slow (stencil and cover) or highly memory intensive (cached prerendered buffers, e.g. most SVG renderers). In truth none of this is necessary; rendering vector graphics on the GPU is not hard if you use, as the saying goes, this one neat trick.

Continue reading Simple GPU Vector Graphics With Spatial Trees

Clothoid Splines

A century ago engineers had very good and robust means of drafting 2D curves using specialized spline sets and curve templates (e.g. French curves).  But these proved difficult to replicate in early computers; the need for fast, simple algorithms drove first Bezier, and then de Boor to embrace the idea of polynomial-based splines.

Creating a spline from independent polynomial functions along the x/y/z axes has a number of problems.  Such splines cannot be represented in arc length form and, more importantly, controlling their curvature functions is not easy.   Polynomial splines are computationally simple but mathematically complex.  

Continue reading Clothoid Splines