DEV Community: Daniel Ferreira Monteiro Alves

Turfano: when the AI helps you admit the first version was wrong

Daniel Ferreira Monteiro Alves — Wed, 22 Jul 2026 17:34:24 +0000

What Turfano is

Turfano is a faithful .NET port of TurfJS — the most widely used geospatial analysis library in JavaScript — with its own GeoJSON types and zero external dependencies in the core package.

using Turfano.GeoJson;

var origin = new Position(-122.4194, 37.7749);
var destination = new Position(-122.4094, 37.7849);

var distance = Geo.Distance(origin, destination); // Turfano.Units.Length
Console.WriteLine($"{distance.Kilometers:F3} km");

var union = Geo.Union(square, overlappingSquare); // Turfano.GeoJson.Geometry?

That's today. Because last October's version was a completely different project — and the difference is the story worth telling.

October 2025: 63% parity, built on top of NetTopologySuite

Before it was called Turfano, the project was called DotTerritory: a wrapper that translated TurfJS's functions using NetTopologySuite (NTS) for geometry types and UnitsNet for quantities. An efficiency report generated by another AI (Devin, October 2025) documents the state of the art back then: 72 of the 114 functions in the @turf index implemented — 63% coverage.

That wasn't nothing. But it was a wrapper — and a wrapper means inheriting the semantics of whatever you're wrapping, not the semantics of whatever you're porting.

The problem that only shows up when you compare against the real source

NTS is an excellent topology engine. But it resolves the same geometric operations with subtly different rules than the original TurfJS: polygon boundary handling, whether the centroid includes the closing vertex, whether nearestPointOnLine is planar or geodesic. Swapping the implementation underneath (re-typing logic that already existed on top of NTS) isn't safe — that's documented, in plain terms, in the spec for the feature that pulls the NTS engine out of the overlay path (specs/009-nts-engine-exit):

When porting functions (parity waves), re-typing existing logic is not safe: validating against the real @turf caught bugs in the NTS-based code (RhumbDestination with the wrong q; nearestPointOnLine planar vs. geodesic; centroid including the closing vertex; Boolean* predicates using NTS boundary semantics instead of Turf's). Always validate each function against the real @turf.

That's the lesson logged — in the project's own lessons-learned file — right after a simpler, earlier one: avoid cryptic acronyms in names (no D2R, no Rtan; prefer RadiansPerDegree, RightTangent — except well-known domain terms, like BBox, lon/lat, and the geodesic notation phi/lambda).

The rewrite: port the real algorithm, not someone else's translation

The decision was to throw away most of the existing surface and port the actual algorithms, validating every single function against the real TurfJS TypeScript source (vendored under reference/, run with Bun):

Overlay (Union/Difference/Intersect/Dissolve): a port of the Martinez–Rueda engine via polyclip-ts — the very source @turf itself runs — instead of delegating to NTS.
Isolines/isobands: marching squares faithful to TurfJS.
Clustering: k-means with deterministic centroids (the first k points), for reproducibility — no hidden randomness.
Buffer: the one operation that stays NTS-bound on purpose, isolated in an optional satellite package.

The result, across two identity rewrites: the package became Turfano (it was DotTerritory) and the main class became Turf (it was Territory, to match TurfJS's own naming — Turf.Area(), Turf.Distance()).

Today: 100% of the @turf index covered by the Geo facade, 295+ tests, 1.0.0-rc.1, zero external dependencies in the core. NTS didn't disappear — it became the Turfano.NetTopologySuite satellite package, for anyone who needs Buffer or already lives in that ecosystem (a public ToNts/FromNts bridge, with a packed-sequence boundary — zero materialized Coordinate objects).

Two bonus finds while re-reading the repo to write this

The lessons-learned file also records that running a subagent editing files in the same working tree while the orchestrator was doing checkout/commit in parallel caused a git race — the documented fix is to isolate that subagent in its own git worktree. The AI documented its own operational mistake so it wouldn't repeat it.

And the project's constitution file (the spec-kit governance "manifesto," .specify/memory/constitution.md) still has the example placeholders — [PRINCIPLE_1_NAME], [GOVERNANCE_RULES] — never filled in. The AI is rigorous enough to validate every ported function against the source; filling out the "why this project exists" template, not so much.

The fast convergence — and what it doesn't replace

The idea of "fast convergence between different systems" (getting a JS ecosystem and a .NET ecosystem to agree, function by function, on the same result) only worked here because every port was checked against the real source — never against the intuition of "it should be similar to what we already had." AI massively speeds up the work of porting the 42 functions that were missing. It doesn't speed up the part where you realize the 63%-covered foundation you already built had bugs too subtle to trust without re-checking — that still takes someone willing to throw away what "mostly worked."

A note on how this was built

Turfano was built with OpenCode running GLM-5.2 — a different tool-and-model pairing than the one used for MySheet (Claude Opus/Sonnet). Two different AIs, two different spec-kit workflows, and the same pattern underneath: a history only becomes a tellable story once someone — human or AI — bothers to write down the why, not just the what.

Turfano is open source. Full code, complete @turf index coverage, and the specs for every parity wave: github.com/danfma/Turfano.

MySheet: the Excel formula engine I learned to audit as fast as I wrote it

Daniel Ferreira Monteiro Alves — Wed, 22 Jul 2026 17:32:22 +0000

What MySheet is

MySheet is a spreadsheet formula engine for .NET. It loads an .xlsx file, re-evaluates the formulas in memory, and hands back the results — no Excel installed, no COM automation, no shelling out.

It doesn't compete with ClosedXML, EPPlus, or NPOI — those libraries remain the right tool for manipulating an Excel file with full fidelity (MySheet's own test suite uses ClosedXML as an independent oracle). MySheet solves a narrower problem:

You keep an Excel workbook on a server as the source of truth for a calculation. You need to load it, re-evaluate it with fresh inputs, and expose or write back the results — repeatedly, with low overhead, and without Excel installed anywhere.

var workbook = new Workbook();
var sheet = workbook.Sheets.Add("Sheet1");

sheet["A1"] = new NumberValue(1);
sheet["A2"] = new NumberValue(2);
sheet["A3"] = ExpressionParser.Parse("=SUM(A1:A2)", sheet);

ComputedValue result = workbook.GetCellValue("Sheet1", "A3");
double total = result.ToDouble(); // 3.0

304 of Excel's ~520 catalogued functions are implemented. Not all 520 — and the README is upfront about it. Cell styling and number formatting are deliberately out of scope: that's not the problem this project set out to solve.

The first number that caught my eye: velocity

I went back through the changelog to write this post and noticed something I hadn't consciously registered: between v0.1.0 and v3.15.0, 19 straight days passed and 53 releases shipped — each one with a changelog note generated from conventional commits.

That number alone doesn't say much good — "fast" by itself isn't a virtue in engineering, it's just a cheaper way to accumulate technical debt if it isn't backed by some form of proof. What separates this from accelerated vibe-coding is what happened in parallel.

Two reorganizations that would break any API — backed by proof, not "trust me"

v2.0 reorganized ~190 public types into category namespaces (Danfma.MySheet.Expressions.Logical, .Mathematics, .Text, and so on) — a 100% compile-time break, zero behavior change. v3.0 encapsulated the Sheet's cell storage behind a single write choke point, laying the groundwork for the reverse dependency graph that came later.

Both shipped with a full migration guide (a type → namespace map, before/after using examples) — and both are covered by the same regression test: a .msgpack binary file saved by version 1.x is loaded and re-evaluated on every build, proving the serialization format stays byte-identical three major versions later. That's not a claim in the README — it's a test that breaks CI if someone gets it wrong.

// 2.x
sheet.Cells["A1"] = new NumberValue(10); // direct mutation of the public dictionary

// 3.0 — Cells became an IReadOnlyDictionary; writes go through one path
sheet["A1"] = new NumberValue(10); // delegates to the SetCell choke point

The July audit: four reports became a phased plan, with before/after numbers

Instead of "we found and fixed some bugs," the repository documents a formal audit from 2026-07-10: four technical reports synthesized into a phased fix plan, each phase shipped as a partial release through a CI workflow, with an explicit author rule — no breaking changes; any candidate for an API break gets pushed to the end and evaluated separately.

Two performance findings, each with a counterfactual benchmark (run without the fix, run with the fix, compare):

RANK.EQ/RANK.AVG used to re-scan the entire range for every single cell — O(n²) on a 5,000-row column. They became two binary searches over the range snapshot's sorted view. The "20 to 40x faster" claim isn't left hanging: the BEFORE benchmark was reverted, run, measured (740ms), then compared against the fix (25ms) — same column, same process.

Recompiling a Regex on every evaluation (in REGEXTEST, in SEARCH's wildcard matching, in the static Criteria.WildcardMatch) became a bounded static cache with a 256-entry cap. A security bonus turned up along the way: Criteria/WildcardMatch had no timeout — a real ReDoS with chained wildcards — now it fails safe as "no match" instead of hanging.

Why this matters more than the speed itself

Nobody here wrote "trust me, it works." Every format change ships with a test that loads the old binary. Every optimization ships with a before/after benchmark right in the text of the fix. This isn't about AI writing code fast — it's about a process that accepts being audited at the same speed it ships.

A note on how this was built

MySheet was built almost entirely with Claude — Opus and Sonnet — including most of the July audit, delegated to subagents phase by phase, reviewed and committed by an "orchestrator" (which is just me, following the process I described above). The changelog, the plans, and the regression tests are what was left over afterward — and, without my planning it, they turned out to be the raw material for this post.

MySheet is open source. Full code, complete changelog, and the list of all 304 functions: github.com/danfma/my-sheet.

Write your domain once in C#, ship idiomatic TypeScript with Metano

Daniel Ferreira Monteiro Alves — Mon, 01 Jun 2026 17:05:58 +0000

If you build a full-stack product with a .NET backend and a TypeScript frontend, you have almost certainly described the same domain twice. The User entity, the Order status enum, the small validation rule, the JSON contract: written once in C#, then mirrored by hand in TypeScript. The mirror drifts. Someone adds a field on one side and forgets the other. A bug ships.

I got tired of maintaining that second copy, so I built Metano.

Metano is a Roslyn-powered transpiler. You keep your domain in C#, as the single source of truth, and Metano generates real TypeScript from it. Not declaration stubs, not just type shapes: actual behavior. Records, methods, operators, guards, LINQ, async, exceptions, and JSON serializer contracts come across as idiomatic TypeScript that fits the tooling you already use.

Why not just use what already exists

A few approaches get close, and each one stops short of what I wanted:

Hand-written type mirrors. The honest baseline, and the one that drifts. Every change is two changes, and the compiler on neither side knows about the other.
OpenAPI / NSwag codegen. Great for client SDKs and DTO shapes, but it generates data shapes, not behavior. Your ToggleCompleted() method does not come along.
Blazor WebAssembly. This ships the .NET runtime into the browser. It is .NET running on the client, not idiomatic TypeScript your frontend team reads and owns, and the runtime weight is real.
Fable. Excellent project, but it is built around F#. If your backend and your team live in C#, that is a language switch, not a code-sharing strategy.

Metano sits in the gap: C# in, idiomatic TypeScript out, with no .NET runtime in the browser and only small helper imports when the emitted code actually needs them.

Show, do not tell

Here is a record written in C#:

using Metano.Annotations;

[assembly: TranspileAssembly]
[assembly: EmitPackage("sample-todo")]

namespace SampleTodo;

[StringEnum]
public enum Priority { Low, Medium, High }

public record TodoItem(string Title, bool Completed = false, Priority Priority = Priority.Medium)
{
    public TodoItem ToggleCompleted() => this with { Completed = !Completed };

    public TodoItem SetPriority(Priority priority) => this with { Priority = priority };

    public override string ToString() => $"[{(Completed ? "x" : " ")}] {Title} ({Priority})";
}

And here is what Metano generates:

export const Priority = {
  Low: "low",
  Medium: "medium",
  High: "high",
} as const;

export type Priority = (typeof Priority)[keyof typeof Priority];

export class TodoItem {
  constructor(
    readonly title: string,
    readonly completed: boolean = false,
    readonly priority: Priority = "medium",
  ) {}

  toggleCompleted(): TodoItem {
    return this.with({ completed: !this.completed });
  }

  setPriority(priority: Priority): TodoItem {
    return this.with({ priority: priority });
  }

  toString(): string {
    return `[${this.completed ? "x" : " "}] ${this.title} (${this.priority})`;
  }

  equals(other: any): boolean {
    return (
      other instanceof TodoItem &&
      this.title === other.title &&
      this.completed === other.completed &&
      this.priority === other.priority
    );
  }

  with(overrides?: Partial<TodoItem>): TodoItem {
    return new TodoItem(
      overrides?.title ?? this.title,
      overrides?.completed ?? this.completed,
      overrides?.priority ?? this.priority,
    );
  }
}

The C# record keeps its value semantics on the TypeScript side. You get structural equals, a non-destructive with, and the string enum rendered as a const object plus a union type, which is the idiom most TS codebases already reach for. No decorators to wire up, no runtime to load, just code your bundler treats like any other module.

How it works

Metano is built on Roslyn, so it understands your C# semantically rather than scraping syntax. The pipeline parses your project, lowers it into a shared intermediate representation, and then emits target code from that IR.

TypeScript is the production target today. There is also an experimental Dart/Flutter backend riding the same IR, which exists mostly to validate that the architecture is genuinely multi-target rather than a TypeScript-shaped special case. Keeping the IR honest is what makes new backends tractable later.

What it handles today

More than I expected to reach when I started:

C# records, classes, structs, interfaces, delegates, inheritance, generics, overloads, extension methods, nullable types, async, exceptions, pattern matching, and nested types.
BCL mappings for collections, LINQ, decimal, Guid, temporal types, BigInteger, tasks, strings, and math.
System.Text.Json source-generation metadata is emitted as a TypeScript SerializerContext, so your serialization contracts stay in sync too.
Output controls via attributes when you want to shape the emitted code: [StringEnum], [PlainObject], [Branded], [GenerateGuard], [ObjectArgs], [Optional], [Import], and more.
Cross-project package generation with [EmitPackage], generated barrels, and package-aware imports.

The generated TypeScript works with Bun, Vite, Vitest, Biome, ESLint, bundlers, and source maps. It behaves like code a person wrote.

Honest scope

Metano is young and moving quickly. TypeScript is the mature, production path; the Dart backend is intentionally documented as experimental while its coverage grows. It is built for sharing domain code and logic, not for porting an entire app or replacing your UI framework, although the repo does include a set of counter samples that explore component and MVU-style patterns, including SolidJS interop, if you want to see how far the idea stretches.

If you are looking for "write C# and never touch the frontend again," that is not what this is. If you are looking for "stop maintaining a second copy of my domain," that is exactly this.

Try it

dotnet add package Metano
dotnet add package Metano.Build

Point your C# project at a generated TypeScript package:

<PropertyGroup>
  <MetanoOutputDir>../my-domain-ts/src</MetanoOutputDir>
  <MetanoClean>true</MetanoClean>
</PropertyGroup>

Then dotnet build. There is also a global tool if you prefer manual runs:

dotnet tool install --global Metano.Compiler.TypeScript
dotnet metano-typescript -p path/to/YourProject.csproj -o path/to/output/src --clean

Repo: https://github.com/danfma/metano
NuGet: https://www.nuget.org/packages/Metano
npm runtime: https://www.npmjs.com/package/metano-runtime

What is next

I will continue to evolve Metano by exploring more use cases and making it more complete, and along the way, I'm evaluating other approaches like JSX generation.

The roadmap I am most curious about is a WebAssembly backend on the same IR, using the modern WasmGC proposal so the output stays lean instead of shipping a runtime. That raises a genuinely interesting compiler problem: how to lower C# value types onto WasmGC's reference-typed structs while preserving copy semantics. I will write that one up separately. Also, evaluate whether using WasmGC will allow me to transfer data between Wasm and JS with minimal friction, which opens up space for more interesting prototypes.

If Metano is useful to you, or if it breaks in an interesting way, I would love your feedback. Issues and stars both help me prioritize.