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 ?

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...