Thomas Seeley

Nix Resources

2026-01-15T00:00:00+00:00

Code

nix

Thomas Seeley

@tseeley.com on Bluesky, @iamseeley on Mastodon

How To Onboard →

How To Onboard

2025-08-05T00:00:00+00:00

Optimize for time-to-value, not signup completion
Never show a completely empty workspace
Single, opinionated first action
Personalize only when the answer changes the experience
Teach by doing, not by tooltips
Earn complexity over time
Define and obsess over one activation milestone
White-glove first to learn, then productize

ux

Thomas Seeley

@tseeley.com on Bluesky, @iamseeley on Mastodon

← Nix Resources · Inferring types from usage →

Inferring types from usage

2025-04-01T00:00:00+00:00

Membrane programs have a persistent state object that survives across deploys. You import it and use it like a regular JavaScript object:

import { state } from "membrane";

state.count ??= 0;

export function increment() {
  return ++state.count;
}

The entire JS heap is durable, but state is the conventional way to pass data between code versions. The question is: what type is state?

We could make developers define a State type for every program. But that’s boilerplate, and for quick scripts and prototypes it slows you down. We already had a TypeScript language service plugin for Membrane’s graph types, so I added state type inference to it.

The Idea

If you write state.count ??= 0, we know state.count is a number. If you write state.apiKey = args.apiKey and args.apiKey is a string, we know state.apiKey is a string. Walk the abstract syntax tree¹, find every assignment to a state property, extract the type from the right-hand side, and generate a type declaration.

The generated type looks like this:

type State = {
  count: number;
  apiKey: string;
  [key: string]: any;
};

That gets injected into the generated membrane.d.ts file. You get autocomplete and type checking on state without writing any type annotations. If you do want to define the type explicitly, export a State type or interface from index.ts and the inference backs off.

The Tricky Parts

The idea is simple, but as always implementation had more edge cases than expected.

Assignment Patterns

Turns out people assign to state in a lot of different ways:

state.count = 0; // direct assignment
state.count ??= 0; // nullish coalescing assignment
state.count ||= 0; // logical OR assignment
state.count += 1; // compound assignment
state.count = value as number; // type assertion

The AST visitor needs to catch all of these. Direct assignments and compound assignments (+=, -=, etc.) fall in a range of operator token kinds between FirstAssignment and LastAssignment, which makes them easy to handle together. Nullish coalescing assignment (??=) is its own token kind and needs a separate check:

if (
  ts.isBinaryExpression(node) &&
  node.operatorToken.kind >= ts.SyntaxKind.FirstAssignment &&
  node.operatorToken.kind <= ts.SyntaxKind.LastAssignment
) {
  processStateAssignment(node.left, node.right);
} else if (
  ts.isBinaryExpression(node) &&
  node.operatorToken.kind === ts.SyntaxKind.QuestionQuestionEqualsToken
) {
  processStateAssignment(node.left, node.right);
}

Nullish Coalescing and `any`

state.count ??= 0 is interesting because the right-hand side is a binary expression with ??. The left side is state.count, which might be any if we haven’t inferred a type for it yet. The right side is 0, which is number.

If we naively get the type of the whole expression, TypeScript might give us any because one side is any. So we check both sides individually:

if (
  node.operatorToken.kind === ts.SyntaxKind.QuestionQuestionToken ||
  node.operatorToken.kind === ts.SyntaxKind.BarBarToken
) {
  const leftType = checker.getTypeAtLocation(node.left);
  const rightType = checker.getTypeAtLocation(node.right);

  const isLeftAny = (leftType.getFlags() & ts.TypeFlags.Any) !== 0;
  const isRightAny = (rightType.getFlags() & ts.TypeFlags.Any) !== 0;

  if (isLeftAny && !isRightAny) return rightType;
  if (!isLeftAny && isRightAny) return leftType;

  return checker.getTypeAtLocation(node);
}

If one side is any and the other is concrete, use the concrete type. If both are concrete, use the union. This is what makes state.count ??= 0 correctly infer number instead of any.

Explicit vs Inferred Priority

Consider this:

state.count ??= 0; // inferred: number
state.count = getCount(); // explicit: number (from getCount's return type)

Both assignments tell us state.count is a number, but they have different confidence levels. A direct assignment (=) is explicit. A nullish coalescing assignment (??=) or logical OR assignment (||=) is inferred, because they’re fallback patterns that might not represent the primary type.

When we see a new assignment to a property we’ve already typed, explicit assignments override inferred ones. More specific types override any. This means the order of assignments in your code doesn’t matter as much as the kind of assignment.

Type Assertions

If you write state.data = response as ApiResponse, the type should be ApiResponse, not whatever TypeScript infers from response. The plugin checks for as expressions and type assertion expressions, unwrapping parenthesized expressions along the way:

function getAssertedType(node: Expression): Type | undefined {
  if (ts.isAsExpression(node) || ts.isTypeAssertionExpression(node)) {
    return checker.getTypeAtLocation(node);
  }
  if (ts.isParenthesizedExpression(node)) {
    return getAssertedType(node.expression);
  }
  // ...
}

How It Fits Together

The inference hooks into getSemanticDiagnostics. Every time the editor updates diagnostics, the plugin walks the AST, collects state assignments, and generates the State type string. If it changed since last time, membrane.d.ts gets regenerated.

If a developer exports their own State type:

export interface State {
  count: number;
  apiKey: string;
}

The plugin detects that and imports it instead of generating one. Explicit always wins.

The General Problem

The technique here isn’t specific to state. It’s a general approach: infer the type of an untyped object by walking all the places it’s assigned to across a codebase. You could apply the same pattern to config objects, environment variables, feature flags, or any global singleton that accumulates properties over time.

TypeScript itself has open issues requesting “infer type from usage” for implicit any parameters, but it’s scoped to a single function body, not whole-program analysis. Flow does whole-program type inference, but that’s an entire type system. TypeStat infers types from usage patterns and writes annotations back into source files, but it targets individual variables and parameters, not a shared object.

The architecture closest to ours is Volar (Vue Language Tools), which generates virtual TypeScript files from .vue single-file components. The pattern is the same: take a non-standard source of type information, generate a .d.ts that the TypeScript language service can understand, and keep it updated as the source changes.

We’re doing a narrower version of that. Walk assignments to one object, build a type from what we find, inject it into a generated declaration file.

What I Learned

Working on this gave me a better feel for TypeScript’s compiler API than anything else I’ve done. The TypeChecker is powerful but not always intuitive. getTypeAtLocation can return any in cases where you’d expect something more specific, especially when the thing you’re checking is a property of an untyped object (which state is, until we infer its type). The getBaseTypeOfLiteralType call is important too. Without it, state.count = 0 would infer the literal type 0 instead of number.

The biggest takeaway: type inference is a game of priorities! You have multiple sources of type information (direct assignments, fallback patterns, type assertions, compound assignments) and you need rules for which one wins. Getting those priority rules right is what makes the experience feel natural instead of surprising.

Abstract Syntax Tree, a tree representation of source code structure.↩︎

typescript membrane

Thomas Seeley

@tseeley.com on Bluesky, @iamseeley on Mastodon

← How To Onboard · Hello, Membrane →

Hello, Membrane

2024-11-10T00:00:00+00:00

It’s been a busy, exciting past few months. I joined membrane.io as an intern in September, and I’m having a great time making improvements to the platform and building things in user space.

What’s Membrane?

Membrane is a serverless platform for developing JavaScript/TypeScript programs.

Every program you create in your Membrane workspace becomes part of your graph, and the programs can connect to each other through this graph.

There are a few key things that set Membrane apart from other serverless platforms:

Programs have built-in state - no need to set up a database
Everything gets logged before it happens - if it’s not in the logs, it didn’t happen
Each program gets an email address - handle incoming emails by exporting an email function
Each program gets its own endpoint - handle HTTP requests by exporting an endpoint function
Programs can use other programs as building blocks through graph connections

What I’ve Been Working On.

Most of my time has been spent on Membrane’s API drivers. Drivers let you interact with external APIs through Membrane’s graph.

I’ve been improving existing drivers like Discord and Anthropic and building a tool to generate new ones. The more drivers on Membrane, the more useful tools and automations we can build!

A driver exposes API endpoints as nodes (fields, actions, events) that you can reference in your graph with a simple syntax.

For example, github:users.one(name:"membrane-io") tells Membrane to get a specific GitHub user - but here’s what’s cool: even though that API call returns all of the user’s data, you can selectively reference just the pieces you need in other programs, like if we want to get their avatar: github:users.one(name:"membrane-io").avatar_url.

Other Projects and Improvements:

Implemented type inference for Membrane state
Dynamic OG images for the changelog, packages, and docs
Made a driver for the Membrane API: mem

I’m excited to start building more drivers and example tools/automations :).

If you’d like to learn more about Membrane check these out:

And join the Discord!

Want to Help Shape Membrane?

We’re looking for developers to try out Membrane and share their feedback!

If you’re interested in participating in user interviews, reach out to me at thomas@membrane.io. We’d love to hear your thoughts and help you get started building tools for yourself or for your company.

membrane javascript

Thomas Seeley

@tseeley.com on Bluesky, @iamseeley on Mastodon

← Inferring types from usage · Neovim Cheatsheet →

Neovim Cheatsheet

2024-10-15T00:00:00+00:00

Basic Navigation

Movement

h j k l - Left, Down, Up, Right
w - Next word start
b - Previous word start
e - End of word
0 - Start of line
^ - First non-blank character
$ - End of line
gg - Start of file
G - End of file
{number}G - Go to line number
% - Jump to matching bracket

Scrolling

Ctrl-d - Half page down
Ctrl-u - Half page up
Ctrl-f - Page down
Ctrl-b - Page up
zz - Center cursor on screen

Editing

Insert Mode

i - Insert before cursor
I - Insert at start of line
a - Append after cursor
A - Append at end of line
o - Open new line below
O - Open new line above
Esc - Exit insert mode

Deletion

x - Delete character under cursor
dd - Delete line
dw - Delete word
d$ - Delete to end of line
d0 - Delete to start of line
{number}dd - Delete N lines

Copy/Paste

yy - Yank (copy) line
yw - Yank word
y$ - Yank to end of line
p - Paste after cursor
P - Paste before cursor
"+y - Copy to system clipboard
"+p - Paste from system clipboard

Undo/Redo

u - Undo
Ctrl-r - Redo
. - Repeat last command

Visual Mode

v - Character-wise visual
V - Line-wise visual
Ctrl-v - Block visual
Select then d to delete, y to copy

Search & Replace

/pattern - Search forward
?pattern - Search backward
n - Next match
N - Previous match
* - Search word under cursor
:%s/old/new/g - Replace all in file
:%s/old/new/gc - Replace with confirmation

File Operations

:w - Save file
:wq or :x - Save and quit
:q - Quit
:q! - Quit without saving
:e filename - Open file
:bn - Next buffer
:bp - Previous buffer

My Custom Keymaps

Leader Key: `<Space>`

VimWiki Specific

<Enter> - Follow/create wiki link
<Backspace> - Go back
<Tab> - Next link
<Shift-Tab> - Previous link
<Ctrl-Space> - Toggle task checkbox

LSP

K - Hover documentation
gd - Go to definition
gr - Find references
<Ctrl-Space> - Trigger completion
<CR> - Confirm completion

Oil.nvim File Explorer

- - Open parent directory
<Enter> - Open file/directory
Edit text to rename
dd - Delete file
o - Create new file
:w - Save changes
q - Close oil

Window Management

:split or :sp - Horizontal split
:vsplit or :vsp - Vertical split
Ctrl-w h/j/k/l - Navigate between windows
Ctrl-w = - Equal window sizes
Ctrl-w q - Close window

Tips & Tricks

Multiple Cursors (Visual Block)

Ctrl-v - Start visual block
Select lines with j/k
I - Insert at start of all lines
Type text, press Esc twice

Macros

q{letter} - Start recording macro
Do actions
q - Stop recording
@{letter} - Replay macro
@@ - Replay last macro

Marks

m{letter} - Set mark
'{letter} - Jump to mark
'' - Jump back to previous position

Command Line

:!command - Run shell command
:r !command - Insert command output
:%!command - Filter file through command

VimWiki Tasks

- [ ] - Create task
Ctrl-Space - Toggle task state - [ ] - Not done - [.] - 0-33% done - [o] - 34-66% done - [O] - 67-99% done - [X] - Done
Nested tasks auto-update parent status

Resources

:help - Neovim help
:help {topic} - Help on specific topic
:Tutor - Interactive Neovim tutorial

cheatsheet

Thomas Seeley

@tseeley.com on Bluesky, @iamseeley on Mastodon

← Hello, Membrane · Maze Playground →

Maze Playground

2024-08-22T00:00:00+00:00

I read Andrew Healey’s Generating Mazes and wanted to see the algorithms work. Not just the finished maze, but each step of the generation. Walls getting removed one at a time, the path carving through the grid.

So I built a small playground for it. Deno, TypeScript, and a <canvas>.

The Data Model

A maze is a grid of cells. Each cell has four walls and knows whether it’s been visited.

export class Cell implements CellInterface {
  position: Position;
  hasTopWall: boolean;
  hasRightWall: boolean;
  hasBottomWall: boolean;
  hasLeftWall: boolean;
  visited: boolean;

  removeWall(neighbor: CellInterface): void {
    const dx = neighbor.position.x - this.position.x;
    const dy = neighbor.position.y - this.position.y;

    if (dx === 1) {
      this.hasRightWall = false;
      neighbor.hasLeftWall = false;
    }
    // ... and so on for each direction
  }
}

removeWall figures out which direction the neighbor is in and removes the wall on both sides. That’s the core operation of maze generation: two cells become connected.

Generators for Stepping

The part I liked most was using JavaScript generators for the algorithms. DFS yields after each step, which means the UI can consume it at whatever pace it wants.

*generateSteps(maze: MazeInterface, startCell: CellInterface): Generator<{ currentCell: CellInterface }> {
  const stack: CellInterface[] = [startCell];
  startCell.visited = true;

  while (stack.length > 0) {
    const currentCell = stack[stack.length - 1];
    yield { currentCell };

    const unvisitedNeighbors = maze.getNeighbors(currentCell)
      .filter(neighbor => !neighbor.visited);

    if (unvisitedNeighbors.length > 0) {
      const randomIndex = Math.floor(Math.random() * unvisitedNeighbors.length);
      const chosenNeighbor = unvisitedNeighbors[randomIndex];
      currentCell.removeWall(chosenNeighbor);
      chosenNeighbor.visited = true;
      stack.push(chosenNeighbor);
    } else {
      stack.pop();
    }
  }
}

The UI runs a setInterval at 50ms that calls generator.next(), snapshots the maze state, and renders it. After generation is done, a slider lets you scrub back through every step. You can watch the algorithm think.

What’s There, What’s Not

Right now only DFS is implemented. The dropdown lists Aldous-Broder, Prim’s, and Kruskal’s but they’re stubs. I’d like to add them eventually because the interesting thing about maze algorithms is how different the mazes feel. DFS creates long winding corridors with few branches. Aldous-Broder creates more uniform, random-looking mazes. Same grid, different character.

The rendering is simple Canvas drawing. Visited cells get a gray fill, the current cell gets a blue highlight, and walls are just lines. Nothing fancy, but it’s enough to see what’s happening.

typescript algorithms

Thomas Seeley

@tseeley.com on Bluesky, @iamseeley on Mastodon

← Neovim Cheatsheet · Scheme-ing →

Scheme-ing

2024-07-04T00:00:00+00:00

I’ve been reading SICP on and off. To be honest, I’ve only made it a few chapters in and I think that’s as far as I’ll go.

Around the same time I read Wolf in White Van by John Darnielle. It’s a novel about a guy who runs a text-based adventure game by mail. Players send in their moves, he sends back what happens. The game is called Trace Italian! The whole book is told in reverse, which gives it this strange gravity. You know where the story ends up before you know how it started.

I thought it would be fun to build a text adventure in Scheme. So I did!

The Game

It’s small. Four rooms, directional movement, a game loop. No items, no puzzles, no win condition. Just the skeleton of a world you can walk around in.

(define rooms
  (list
   (list 'living-room "You are in the living room. There is a door to the north and a kitchen to the west.")
   (list 'kitchen "You are in the kitchen. There is a living room to the east.")
   (list 'hallway "You are in the hallway. There is a living room to the south and a bedroom to the north.")
   (list 'bedroom "You are in the bedroom. There is a hallway to the south.")))

Rooms are lists. Connections between rooms are lists. The game state is which room you’re in.

(define (game-loop)
  (describe-current-room)
  (let ((command (get-command)))
    (cond ((eq? command 'north) (move 'north))
          ((eq? command 'south) (move 'south))
          ((eq? command 'east) (move 'east))
          ((eq? command 'west) (move 'west))
          ((eq? command 'quit) (display "Goodbye!")
                                (newline)
                                (exit))
          (else (display "Invalid command.")
                (newline)))
    (game-loop)))

The game loop is a recursive function that describes where you are, reads a command, acts on it, then calls itself. No while loop, no mutable iterator. Just a function that calls itself forever until you quit.

It’s a good reminder that you don’t need much to make something interactive. Four rooms and a prompt. That’s a world you can walk around in.

The full source is about 60 lines. There’s also a tic-tac-toe in the same repo from the same weekend.

scheme

Thomas Seeley

@tseeley.com on Bluesky, @iamseeley on Mastodon

← Maze Playground