Inferring types from usage

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

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

import</span> {</span> state</span> }</span> from</span> "</span>membrane</span>"</span>;</span></span>
</span>
state</span>.</span>count</span> ??=</span> 0</span>;</span></span>
</span>
export function</span> increment</span>() {</span></span>
  return</span> ++</span>state</span>.</span>count</span>;</span></span>
}</span></span></code></pre>
The entire JS heap is durable, but state</code> is the conventional way to pass data between code versions. The question is: what type is state</code>?</p>
We could make developers define a State</code> 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.</p>
The Idea</a></h2>
If you write state.count ??= 0</code>, we know state.count</code> is a number</code>. If you write state.apiKey = args.apiKey</code> and args.apiKey</code> is a string</code>, we know state.apiKey</code> is a string</code>. Walk the abstract syntax tree (AST</a>), find every assignment to a state</code> property, extract the type from the right-hand side, and generate a type declaration.</p>
The generated type looks like this:</p>
type</span> State</span> = {</span></span>
  count</span>: number;</span></span>
  apiKey</span>: string;</span></span>
  [</span>key</span>: string]: any;</span></span>
};</span></span></code></pre>
That gets injected into the generated membrane.d.ts</code> file. You get autocomplete and type checking on state</code> without writing any type annotations. If you do want to define the type explicitly, export a State</code> type or interface from index.ts</code> and the inference backs off.</p>
The Tricky Parts</a></h2>
The idea is simple, but as always implementation had more edge cases than expected.</p>
Assignment Patterns</a></h3>
Turns out people assign to state</code> in a lot of different ways:</p>
state</span>.</span>count</span> =</span> 0</span>;</span> // direct assignment</span></span>
state</span>.</span>count</span> ??=</span> 0</span>;</span> // nullish coalescing assignment</span></span>
state</span>.</span>count</span> ||=</span> 0</span>;</span> // logical OR assignment</span></span>
state</span>.</span>count</span> +=</span> 1</span>;</span> // compound assignment</span></span>
state</span>.</span>count</span> =</span> value</span> as</span> number;</span> // type assertion</span></span></code></pre>
The AST visitor needs to catch all of these. Direct assignments and compound assignments (+=</code>, -=</code>, etc.) fall in a range of operator token kinds between FirstAssignment</code> and LastAssignment</code>, which makes them easy to handle together. Nullish coalescing assignment (??=</code>) is its own token kind and needs a separate check:</p>
if</span> (</span></span>
  ts</span>.</span>isBinaryExpression</span>(</span>node</span>) &&</span></span>
  node</span>.</span>operatorToken</span>.</span>kind</span> >=</span> ts</span>.</span>SyntaxKind</span>.</span>FirstAssignment</span> &&</span></span>
  node</span>.</span>operatorToken</span>.</span>kind</span> <=</span> ts</span>.</span>SyntaxKind</span>.</span>LastAssignment</span></span>
) {</span></span>
  processStateAssignment</span>(</span>node</span>.</span>left</span>,</span> node</span>.</span>right</span>);</span></span>
}</span> else if</span> (</span></span>
  ts</span>.</span>isBinaryExpression</span>(</span>node</span>) &&</span></span>
  node</span>.</span>operatorToken</span>.</span>kind</span> ===</span> ts</span>.</span>SyntaxKind</span>.</span>QuestionQuestionEqualsToken</span></span>
) {</span></span>
  processStateAssignment</span>(</span>node</span>.</span>left</span>,</span> node</span>.</span>right</span>);</span></span>
}</span></span></code></pre>Nullish Coalescing and any</code></a></h3>
state.count ??= 0</code> is interesting because the right-hand side is a binary expression with ??</code>. The left side is state.count</code>, which might be any</code> if we haven’t inferred a type for it yet. The right side is 0</code>, which is number</code>.</p>
If we naively get the type of the whole expression, TypeScript might give us any</code> because one side is any</code>. So we check both sides individually:</p>
if</span> (</span></span>
  node</span>.</span>operatorToken</span>.</span>kind</span> ===</span> ts</span>.</span>SyntaxKind</span>.</span>QuestionQuestionToken</span> ||</span></span>
  node</span>.</span>operatorToken</span>.</span>kind</span> ===</span> ts</span>.</span>SyntaxKind</span>.</span>BarBarToken</span></span>
) {</span></span>
  const</span> leftType</span> =</span> checker</span>.</span>getTypeAtLocation</span>(</span>node</span>.</span>left</span>);</span></span>
  const</span> rightType</span> =</span> checker</span>.</span>getTypeAtLocation</span>(</span>node</span>.</span>right</span>);</span></span>
</span>
  const</span> isLeftAny</span> = (</span>leftType</span>.</span>getFlags</span>() &</span> ts</span>.</span>TypeFlags</span>.</span>Any</span>) !==</span> 0</span>;</span></span>
  const</span> isRightAny</span> = (</span>rightType</span>.</span>getFlags</span>() &</span> ts</span>.</span>TypeFlags</span>.</span>Any</span>) !==</span> 0</span>;</span></span>
</span>
  if</span> (</span>isLeftAny</span> && !</span>isRightAny</span>)</span> return</span> rightType</span>;</span></span>
  if</span> (!</span>isLeftAny</span> &&</span> isRightAny</span>)</span> return</span> leftType</span>;</span></span>
</span>
  return</span> checker</span>.</span>getTypeAtLocation</span>(</span>node</span>);</span></span>
}</span></span></code></pre>
If one side is any</code> and the other is concrete, use the concrete type. If both are concrete, use the union. This is what makes state.count ??= 0</code> correctly infer number</code> instead of any</code>.</p>
Explicit vs Inferred Priority</a></h3>
Consider this:</p>
state</span>.</span>count</span> ??=</span> 0</span>;</span> // inferred: number</span></span>
state</span>.</span>count</span> =</span> getCount</span>();</span> // explicit: number (from getCount's return type)</span></span></code></pre>
Both assignments tell us state.count</code> is a number</code>, but they have different confidence levels. A direct assignment (=</code>) is explicit. A nullish coalescing assignment (??=</code>) or logical OR assignment (||=</code>) is inferred, because they’re fallback patterns that might not represent the primary type.</p>
When we see a new assignment to a property we’ve already typed, explicit assignments override inferred ones. More specific types override any</code>. This means the order of assignments in your code doesn’t matter as much as the kind of assignment.</p>
Type Assertions</a></h3>
If you write state.data = response as ApiResponse</code>, the type should be ApiResponse</code>, not whatever TypeScript infers from response</code>. The plugin checks for as</code> expressions and type assertion expressions, unwrapping parenthesized expressions along the way:</p>
function</span> getAssertedType</span>(</span>node</span>:</span> Expression</span>):</span> Type</span> | undefined {</span></span>
  if</span> (</span>ts</span>.</span>isAsExpression</span>(</span>node</span>) ||</span> ts</span>.</span>isTypeAssertionExpression</span>(</span>node</span>)) {</span></span>
    return</span> checker</span>.</span>getTypeAtLocation</span>(</span>node</span>);</span></span>
  }</span></span>
  if</span> (</span>ts</span>.</span>isParenthesizedExpression</span>(</span>node</span>)) {</span></span>
    return</span> getAssertedType</span>(</span>node</span>.</span>expression</span>);</span></span>
  }</span></span>
  // ...</span></span>
}</span></span></code></pre>How It Fits Together</a></h2>
The inference hooks into getSemanticDiagnostics</code>. Every time the editor updates diagnostics, the plugin walks the AST, collects state</code> assignments, and generates the State</code> type string. If it changed since last time, membrane.d.ts</code> gets regenerated.</p>
If a developer exports their own State</code> type:</p>
export interface</span> State</span> {</span></span>
  count</span>: number;</span></span>
  apiKey</span>: string;</span></span>
}</span></span></code></pre>
The plugin detects that and imports it instead of generating one. Explicit always wins.</p>
The General Problem</a></h2>
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.</p>
TypeScript itself has open issues</a> requesting “infer type from usage” for implicit any</code> parameters, but it’s scoped to a single function body, not whole-program analysis. Flow</a> does whole-program type inference, but that’s an entire type system. TypeStat</a> infers types from usage patterns and writes annotations back into source files, but it targets individual variables and parameters, not a shared object.</p>
The architecture closest to ours is Volar</a> (Vue Language Tools), which generates virtual TypeScript files from .vue</code> single-file components. The pattern is the same: take a non-standard source of type information, generate a .d.ts</code> that the TypeScript language service can understand, and keep it updated as the source changes.</p>
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.</p>
What I Learned</a></h2>
Working on this gave me a better feel for TypeScript’s compiler API</a> than anything else I’ve done. The TypeChecker</code> is powerful but not always intuitive. getTypeAtLocation</code> can return any</code> 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</code> is, until we infer its type). The getBaseTypeOfLiteralType</code> call is important too. Without it, state.count = 0</code> would infer the literal type 0</code> instead of number</code>.</p>
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.</p>


typescript membrane
Thomas Seeley
@tseeley.com on Bluesky, @iamseeley on Mastodon, @iamseeley on GitHub

Hello, Membrane

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

It’s been a busy, exciting past few months. I joined membrane.io</a> 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?</a></h2>
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.
</video>
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</li>
Everything gets logged before it happens - if it’s not in the logs, it didn’t happen</li>
Each program gets an email address - handle incoming emails by exporting an `email</code> function</li>`
`Each program gets its own endpoint - handle HTTP requests by exporting an endpoint</code> function</li>`
`Programs can use other programs as building blocks through graph connections</li> </ul>`What I’ve Been Working On.</a></h2> 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</a> and Anthropic</a> and building a tool</a> 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")</code> 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</code>. Other Projects and Improvements: Implemented type inference for Membrane state</code></li> Dynamic OG images for the changelog, packages, and docs</li> Made a driver for the Membrane API: mem</a></li> </ol> I’m excited to start building more drivers and example tools/automations :). If you’d like to learn more about Membrane check these out: Justin Bennett: Membrane, A Living Computational Environment</a></li> Juan Campa - devtoolsFM episode</a></li> Membrane Changelog</a></li> Membrane Docs</a></li> </ul> And join the Discord</a>! Want to Help Shape Membrane?</a></h2> 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</a>. We’d love to hear your thoughts and help you get started building tools for yourself or for your company. Be on the lookout for some updates coming to Membrane...soon you'll be able to create UIs with the programs on your graph!</aside> membrane javascript Thomas Seeley @tseeley.com on Bluesky, @iamseeley on Mastodon, @iamseeley on GitHub

Thomas Seeley

How To Onboard

Inferring types from usage

Hello, Membrane

Scheme-ing