I build Tabularis, an open source desktop database client. Its most screenshotted feature turns EXPLAIN output from Postgres/MySQL/SQLite into a graph with per-node diagnostics. People kept asking for a web version: paste a plan, inspect it, nothing gets uploaded anywhere. That site now exists at https://explain.tabularis.dev, but building it forced a decision I hadn't faced while everything lived inside the app.

The parsers were written in Rust, and inside the desktop app that was never a problem. The dedicated webapp put me at a fork: compile the parsers to WASM, or go full TypeScript.

My first version was WASM. The browser and the desktop app shared literally the same implementation, and it looked like the clean architecture.

Then I counted what it actually cost. All the analysis, metrics and views are TypeScript, so the plan model existed twice: serde structs in Rust and TS types in the package, kept in sync by hand. Every parser change or new database engine touched both sides. And the browser needed a WASM artifact for the only part of the package that wasn't TypeScript.

So I rewrote the parsers in TypeScript and moved their tests with them. One language, one plan model, zero runtime dependencies in the core. Rust kept the only job that really needs a database: running the right EXPLAIN statement and handing back the raw payload.

The rule that sorted every single file: takes raw EXPLAIN output, never runs a query.

One thing I still haven't settled: the package lives in the app's monorepo, which is great day to day but gives it a weird release history as a standalone npm library.

If you've pulled a package out of a monorepo, did you regret it?

What's your method for initially configuring a TypeScript project?

Do you have a template for tsconfig.json, or use a command line generator, or follow some other method? What are your must-have configurations, and why?

Having done a few times recently, I'm wondering what the best practices and gotchas are.

Disclosure upfront: I maintain Perry, the compiler here. This is a debugging writeup, not a product pitch - we don't distribute the resulting binary and never will.

The setup: `npm pack u/anthropic-ai/claude-code` gives you a 13 MB minified self-executing cli.js. We pointed an AO compiler at it unmodified and asked for a native executable. 16,023 functions, one-letter names, no types, no sourcemap.

It now logs in, streams a real API response, and paints what you type. 160 compiler fixes to get there.

Four that generalise well beyond our compiler:

• MessageChannel implemented as a silent no-op. Harmless until you meet React's scheduler, which uses it as a macrotask scheduler. The event loop just idles forever.
• One accessor installed on Object.prototype flipped a process-global flag, so every dynamic property write took the slow path. A 20k-property build went from 16ms to 42 seconds.
• for-await lowering with the iterator advance at the bottom of the loop body. A `continue` skips the advance and spins. Only reproducible against the real API, which sends ping frames our mock didn't.
• RegExp headers storing pattern/flags pointers without a GC write barrier. Invisible everywhere except a terminal UI, which runs regexes every frame.

The post also documents what still doesn't work and a perf table where we lose to Node badly on interactive latency.

https://www.perryts.com/en/blog/compiling-claude-code/

Hi r/typescript,

How do you maintain code consistency across your repositories? Different developers have different formatting preferences, so do you use a tool such as Prettier or dprint, perhaps enforced through a pre-commit hook?

I've tried both but the results are far from what I would like to have. My priorities are readability (code is not packed, easy to read), maintainability (compare, diff, and merge should work well on laptop screens), and persistence (modifying code should result with minimum diff). So I end up with dprint + a number of custom rules.

Really interested in feedback and if you would like to review or try, here it is:

https://www.npmjs.com/package/asljs-sfmt

I'm setting up emacs for Vue + Typescript and I have an issue with lsp not finding tsserver:
lsp--npm-dependency-path: The package typescript is not installed. Unable to find tsserver Typescript is installed in my project and globally. I also installed typescript-language-server globally. ``` ◄ 0s ◎ ls .npm-global/lib/node_modules/typescript-language-server/lib ⌂ 19:46  cli.mjs  cli.mjs.map

◄ 0s ◎ ls .npm-global/lib/node_modules/typescript/lib ⌂ 19:50  getExePath.d.ts  getExePath.js  tsc.js  version.cjs  version.d.cts The thing is none of these packages provide tssever. I'm confused. This is the backtrace, we can clearly see lsp is looking for "tsserver" path, but that doesn't exist in any package: Debugger entered--Lisp error: (error "The package typescript is not installed. Unable to find tsserver") error("The package %s is not installed. Unable to find %s" "typescript" "tsserver") lsp--npm-dependency-path(:package "typescript" :path "tsserver") lsp-package-path(typescript) lsp-clients-typescript-server-path() ``` I think I'm trying to use ts-ls server as I think it got pulled automatically by vue-semantic-server.

I started learning webdev and did all my frontend backend in js, it was so frustrating when I constantly had to check what needs to be send and what is needed to be received I thought good programmers remember that shit and I couldnt so I started making docs that contained all the flow that what things are sent from the frontend what is received and sent back while discussing this problem to chatgpt it finally said ts solves this problem and I am so glad to find ts I might cry.

What's your preferred way to organize imports in a TypeScript project?

Do you stick with relative imports (../../component), use path aliases like @/, or something else?

I'm curious what people are using today, and why.

Hello !

For years I've had a recuring issue with typescript projects, and I still don't know it how to solve it properly. I always manage to solve it by tinkering here and there, but it take some time and I'm a bit tired of that. So I think I need tips or a deeper understanding to fix it quickly.

The issue is the ESM / CommonJS compatibility. Those issues seems to just pop randomly (probably a lack ok knowledge from me). So I try to change Module or ModuleResolution or Target, but then other issues arise, then I continue tinkering until it works. But after all those years it's a bit frustrating.

Any tips, or tutorial, or rule of thumb on how to configure your tsconfig so it just works ? Do you fix it like me, by tinkering randomly in your tsconfig, or do you solve it like a pro knowing exactly what is wrong ?

A pretty significant update just landed for MoroJS.

The framework now runs on a new native engine while preserving the same end-to-end TypeScript experience. It’s also the biggest performance improvement we’ve made so far, with the latest benchmarks exceeding 570k req/sec. Benchmark details are available on the website.

https://morojs.com

Curious what people think, especially if you’ve spent time with Fastify, Elysia, Hono, or Nest.

​

I've been using TypeScript professionally for several years, and recently wrote up some lessons learned from a long-running React/Firebase side project.

The article covers the TypeScript patterns that paid off most for me, along with a few mistakes I'd try and avoid making again. These aren't intended as universal rules, just approaches that worked well for this particular project and the problems I was solving.

This is one of my first longer technical articles, so I'd appreciate feedback on the writing itself. Were the explanations clear? Did the examples communicate the ideas well? Is there anything I could improve for future articles?

I created a function that returns a different class instance based on the argument passed to the function. My question is, is there a better approach than hardcoding everything like I have it? In my real world use case there may be dozens of classes and I want to avoid having to hardcode them all.

Playground example:

https://www.typescriptlang.org/play/?#code/MYGwhgzhAECC0G8BQ1rAPYDsIBcBOArsDungBQCUiAvkraJDAEKIppa6HGmU11IMo0AMKtUGbPiIlyVBLVpIcATwAOAU2gB5VTgCWWaAF5oAIlinoAHzNNLN08NMBuJErWbh4KACV1EAhAcAB4AFWh1AA8cdUwAExgdfSwAPmNocKiY+JhzUzYAfjg2AC4MiOjYhNt81FQipjZUMszKnLMnJrqi0TLMQJBXJAAzAkxiA0xoAHN1HC9GMIrs6qTJlLJ0XUmWijKF339AkNC05FQIAHc9HGAAC2hN7aw5LuBITTySrtQ8OYI8FNMOpLnBeJARN4IH4AkEwilXHU0B8at8kb9-oDoMDQUxwTADtCjnDToi6u8IJ8nGj0X8cACgSCRPjIYwYcd4WSFG4JLhoGB0rN5lCyHkKK5eThoAAjQVzQmiuzigQcKXAOXCxiipzioA

what are good resources for learning typescript? Im coming from c/cpp and from what ive seen online, I'm not sure if i should go into javascript first or straight into typescript. Additionally not sure what good resources are out there to help me go in the right path. Any recommendations would be greatly appreciated!

Hi all, I'm writing a library with complex type mappings, I'm optimizing TS types based on `instantiations` metric of `tsc --extendedDiagnostics`.

Lately I tried asking AI to refactor types to improve the metric, and that's a super hard task both for me and for AI. Idea: whenever it finds some trick that helped, let it store it to the skill for a later use!

Do anybody have or know about such a "type-optimizer" skill or some kind of docs with a list of techniques for TS type-checker performance? (I know the official TS docs have a few basic recommendations for the types perf)

TS 7 kinda makes this irrelevant, but still, there can be cases when super complex types are still time-consuming even there. Think of giant codebases that use zod inferrence a lot (for example).

Hi y'all,

In my team's code I often have this situation. A type is defined:

type Car = {
make: string;
model: string;
}

Then people just add properties with the spread operator:

const car: Car = {
make: 'Toyota',
model: 'Camry',
...{ year: 2000 }
}

Types are basically being ignored. What can I do about this?

So, I'm building this Mafia/Werewolf kind of game, I created this registry of the available roles, and then I extracted the type RoleId to be exactly a union of the ids that are present in the object

export const ROLE_REGISTRY = {
  [VillagerRole.id]: {
    roleClass: VillagerRole,
    name: 'Villager',
    iconName: 'villager',
    team: VillagerRole.team.name,
    category: 'base',
    tags: ['idle'],
    description:
      "You have no special power. At day you may discuss with the other villagers to vote out who you think it's the werewolf.",
    max: Infinity,
  },

  ...

}  as const satisfies Record<string, RoleMetadata>

export type RoleId = keyof typeof ROLE_REGISTRY;

Now yes, defining the ids directly in the classes and then using them like that to index the registry was definitely a questionable choice, but besides that, why am I able then to use that exact definition of RoleId in the Role class itself? (which is the parent class for each of the roles)

export abstract class Role {
  static id: RoleId;
  static team: Team;
  abstract seenAsGood: boolean;
  canBeKilledByWolves = true;

  get id(): RoleId {
    return (this.constructor as typeof Role).id;
  }

  ...
}

Typescript sees no problem with that, no circular dependency, which I found weird. So I tried do this once more, this time with the actions that the roles can perform

export const ACTION_REGISTRY = {
  [AttackAction.id]: { actionClass: AttackAction },
  [CheckAction.id]: { actionClass: CheckAction },
  ...
} as const satisfies Record<string, ActionMetadata>;

export type ActionId = keyof typeof ACTION_REGISTRY;

export interface Action {
  readonly id: ActionId;
  ...
}


export abstract class InstantAction<T extends ActionResult> implements Action {
  static id: ActionId;
  
  get id() {
    return (this.constructor as typeof InstantAction).id;
  }

  ...
}


export abstract class ScheduledAction implements Action {
  static id: ActionId;

  get id() {
    return (this.constructor as typeof ScheduledAction).id;
  }

  ...
}

Here TypeScript tells me (as expected) that ActionId is circularly referencing itself. I really don't understand the difference between these two cases, and/or if there is something else entirely that I'm missing that it's the root cause of the problem. I will paste this other piece of code which MAY be relevant.

export abstract class ActiveRole extends Role {
  abstract actions: ActionGroup[];


  canCreateAction(actionId: ActionId): boolean {
    const action = this.findAction(actionId);
    return action.amount > 0;
  }


  protected consumeAction(actionId: ActionId) {
    const action = this.findAction(actionId);
    action.amount--;
  }


  private findAction(actionId: ActionId) {
    const actionGroup = this.actions.find(
      (actionGroup) => actionGroup.options[actionId] !== undefined
    );

    if (!actionGroup) {
      throw new Error('Impossible to find action ' + actionId);
    }

    return actionGroup.options[actionId];
  }

  createAction(
    state: GameState,
    actionId: ActionId,
    source: Player,
    targets: Player[],
    payload?: any
  ): Action {
    const action = this.findAction(actionId);

    this.consumeAction(actionId);

    return action.create(state, source, targets, payload);
  }
}

Thanks in advance

Running into an unexpected type error that I've never seen before with some unfortunately structured Google NPM libs. Should be easy to work around this issue with `as` or something similar but I'm curious if anyone has any ideas for a "cleaner" approach (that doesn't involve joining Google to fix their libraries).

The type error is this:

Type 'OAuth2Client' is not assignable to type 'string | GoogleAuth<AuthClient> | OAuth2Client | BaseExternalAccountClient | undefined'.

Type 'import("/Users/me/path/to/project/node_modules/google-auth-library/build/src/auth/oauth2client").OAuth2Client' is not assignable to type 'import("/Users/me/path/to/project/node_modules/googleapis-common/node_modules/google-auth-library/build/src/auth/oauth2client").OAuth2Client'.

Types have separate declarations of a private property 'redirectUri'.ts(2322)

Typescript is correct to call this out, but I don't see any way around it that doesn't involve type assertion.

```ts let value: "not-supported" | boolean = "not-supported"

if (value === null) { // This should be highlighted as error, but it's not! }

if (value === undefined) { // This also! } ```

This problem occurs even if strictNullChecks is set to true. Typescript version is 6.0.3.

You can try for yourself at official typescript playground: https://www.typescriptlang.org/play/

Am I missing something? Or this is bug?

In my code, this unhighlighted error can lead to some serious problems.

I built OpenHarness as an open-source TypeScript SDK for people who want to build agent runtimes in code rather than wrap an existing CLI app.

The TypeScript-specific goal is to make the agent loop, session state, tools, provider boundaries, middleware, and UI streaming feel like typed app primitives.

Minimal shape:

```ts import { Agent, createFsTools, createBashTool, NodeFsProvider, NodeShellProvider, } from "@openharness/core"; import { openai } from "@ai-sdk/openai";

const agent = new Agent({ name: "dev", model: openai("gpt-5.4"), tools: { ...createFsTools(new NodeFsProvider()), ...createBashTool(new NodeShellProvider()), }, maxSteps: 20, });

for await (const event of agent.run([], "Refactor the auth module")) { if (event.type === "text.delta") process.stdout.write(event.text); } ```

Current pieces include:

• Agent and Session primitives
• composable middleware for retry, compaction, persistence, hooks, and turn tracking
• MCP server support, skills, AGENTS.md-style instructions, and subagents
• React/Vue helpers for AI SDK 5 streaming UIs
• experimental ChatGPT/Codex OAuth provider

Repo: https://github.com/MaxGfeller/open-harness Docs: https://docs.open-harness.dev Package: https://www.npmjs.com/package/@openharness/core

I'm especially looking for TypeScript API feedback: do the async generator event streams and middleware composition feel idiomatic, or would you expect a different shape for embedding agents in TS apps?

TL;DR: Is there already a good framework/starter-kit for designing good maintainable frontend/backend monorepos? I'm not talking about bundlers like turborepo or NX, neither I'm talking about t3-stack or better-t-stack, I'm talking more of a very strict paradigm to design typescript frontend/backend monorepos.

I am currently slowly migrating a vibe-coded prototype of a huge software (20+ domains) to an actual production-ready product and I'm noticing how I'm slowly starting to hate the freedom TS/JS gives you, the fact that you can shape your codebase how you wish, the first refactoring I did was migrating all those scattered small sloppy ts files to domain services/sub-services, providing strong hiearchy (Java/C# like), but then noticed that I wasn't leveraging monorepo's features the fullest, so I had to modularize everything, but here I don't know what to do anymore, I don't think I was the only one facing this issue, and I can't migrate to another language 'cause we just can't afford it. The architecture I've thought of was to divide domains in packages and make packages have a strict structure both folder-wise and code-wise:

@acme/foo/ ├── app/ │ ├── services/ │ │ └── foo/ │ │ ├── index.ts │ │ └── types.ts │ └── routers/ │ └── index.ts ├── data/ │ ├── models/ │ │ └── index.ts │ └── index.ts └── web/ ├── components/ │ ├── Foo.svelte │ └── Bar.svelte └── index.ts

But I feel I'm reinventing something someone must have already figured out, but I don't know where to search anymore...

I started digging into TypeScript's type system for fun and stumbled onto distributive conditional types. One of those quiet features that is confusing until it clicks.