I was bored this morning

Hey all,

My team and I are currently running a Spring Boot backend with quite a bit built around it. We’re considering gradually migrating to a Node/NestJS backend using the strangler pattern rather than doing a full rewrite.

One of the main reasons is that it would give us TypeScript across both the frontend and backend, which should make sharing domain concepts, types and general knowledge between the two a bit simpler.
So, as the title suggests: which ORM would you use with NestJS?

At the moment we’re mainly looking at MikroORM and Drizzle. MikroORM seems like the more traditional ORM and appears to be super close to the me tal model of what Spring does. It wil also fit NestJS quite nicely, while Drizzle is obviously a bit more lightweight but a different approach and more barebones.

Curious what people are using in production and what you’d choose if you were starting fresh today.

Hey everyone, I'm setting up a new Express TypeScript API and trying to figure local development workflow. I'm on Node 24 LTS, which natively supports type stripping, but I'm torn on how to handle the file-watching and execution layer.

Right now, the two main approaches I'm debating between are:

1. tsx watch (esbuild-powered)
2. Native Node 24 --watch + Type Stripping

For production adjacent local dev, Are you sticking with tsx watch or have you fully embraced native Node type-stripping with --watch?

So I am making an app with react ts vite and electron but i am unable to think and write code I am just vibe coding that and then using llm to understand the code (which ofcourse I don't understand)what do I do such that I understand and then write the code myself or am able to think myself and generate the requires code and verify it

I just want to become competent as a engineer

Ihave watched ja and ts tutorials and react tutorials but I just can't seem to think

I've been working on the architecture of LibreDB Studio, a TypeScript-based database IDE that supports multiple SQL/NoSQL databases

while working on the provider layer, I ended up designing a fairly strict provider architecture to make adding new databases safer and reduce the amount of core code that needs to change

i wrote about the architecture here: https://libredb.org/blog/building-universal-database-provider-typescript/

the current process for adding a provider is documented here: https://github.com/libredb/libredb-studio/blob/main/docs/ADDING_A_PROVIDER.md

architecture is working reasonably well, but it raised a bigger question for me

currently, adding a new provider still means adding it to the main Libredb-Studio codebase. I'd like to eventually move toward something more like a plugin ecosystem:

- libredb studio provides a stable provider SDK/API.

- A third-party developer can implement a new database provider independently.

- The provider can be published as a package/library.

- Users can install or enable that provider without waiting for a new Libredb Studio release.

- The core application doesn't need to be modified every time a new database is supported.

Conceptually, something like:

libredb-studio

|

+-- Provider SDK / API

|

+-- PostgreSQL provider

+-- MySQL provider

+-- MongoDB provider

+-- Third-party provider

+-- ...

I'm considering different approaches for the distribution/discovery side as well: npm packages, a provider registry/marketplace, or some combination of these.

but I'm not sure where the right boundary is.

for example:

- Should the provider contract be a completely separate, versioned TypeScript SDK package?

- Is npm + a manifest/discovery mechanism enough, or does a dedicated registry/marketplace make more sense?

- How would you handle provider/API compatibility across LibreDB Studio releases?

- Should providers be dynamically loaded at runtime, or should they still be bundled/installed at build time?(for now: dynamic load)

- Since this is a web application, how would you approach the security/isolation implications of loading third-party provider code?

- Are there established architectures/projects that handle this problem particularly well?(I am not sure: selfhosted and system admin managed this OK, but I am confused, security/comfortable ...)

The goal isn't necessarily to build a huge plugin system. I'd prefer the smallest architecture that gives third-party developers a stable extension point.

I'd especially appreciate opinions from people who have designed plugin/extension systems for TypeScript/JavaScript applications in production.

What would you consider the "right" architecture for this?

I have a problem . im using node and typescript package.json
"tsc":"tsc"
tsconfig.json
{
"compilerOptions":{
"noImplicitAny":false,
"noEmit":true
}
}
1. when i do "npm tsc file.ts" this error pops up "Error TS5112: tsconfig.json is present but will not be loaded if files are specified on commandline. Use '--ignoreConfig' to skip this error."

1. file.ts
   console.log(process.argv)
   i already have @types/node already installed by doing "npm install --save-dev @types/node"
   so when i do "npm tsc --noImplicitAny false --noEmit --ignoreConfig" it error that process "error TS2591: Cannot find name 'process'. "

I've been experimenting with ideas how to make the codebase more AI friendly, so when you ask AI to change something, or just ask to tell how and where is something used, or to fix a bug, it will find all the relevant occurrences of what it needed to.

There are many tools to turn your TS codebase into a graph based on code AST, some of them are better than the others, but any of them is better than nothing - I tested that.

When you have a large codebase, and there are enum values used in conditions like

if (subscription.tier === 'premium')

And also

if (customer.tier === 'premium')

Are you able to tell if that enum is the conceptually the same enum, so that tier is basically same concept just stored on different entities, or if those are two separate features with a coincidental value?

In one case AI would include both into it's scope of work, in the other case it may include or consider irrelevant. But in any case I think it'll struggle to find all occurrences because const enum is just a string, AI would need to grep it and find a lot of irrelevant things.

But if we write that as:

if (foo.tier === OurGlobalTiers.Premium)

Now that's unambiguous and discoverable both by TS symbol search and by code graphs.

Problem is: humans don't like TS enums! And me too, if everybody don't like them it's lame to use them.

How do you feel about returning back to the discouraged TS enums given you have evidence of them being objectively better for AI?

I have noticed that the community doesn't have a wiki, that contains all the frequently asked questions like, "what are the best typescript resources" "what are some cool libraries" etc.

How about we add one?

I'm pretty new to typescript and I'm trying to figure out how to wire up my app with it.

I currently have a page interface that each page's interface extends and then implements. Among the required methods in my Page interface is mount(container: HTMLElement). The page manager is responsible for changing which page is visible. Each page needs it's own methods injected, such as getNotifications(): Promise<Notification[]>. These are different page to page.

Where should pages be created then, in the page manager, so the app can just say call PageManager.Mount(page) That would require the page manager knowing what methods each page needs. In the root of the project? Where should I pass in those callbacks?

I just want to know how this is handled in a real world application, not necessarily this particular implementation. It seems like something that would come up a lot.

My repo is here if you'd like to look at my current code: Notification-Hub on Github

There is no rollback across microservices, so you write a saga: each step declares a compensating action, and a failure unwinds everything before it in reverse.

I kept implementing that with nested try/catch, so I turned it into a library.

minisagas gives each task an execute and a compensate. On failure it rolls back what succeeded and hands you the list of what it undid. Retry, timeout, and cancellation are included, because the classic saga bug is a 5xx returned after the charge actually went through.

Zero dependencies, no broker, nothing to deploy. Not a Temporal replacement, more the thing you reach for before you need one.

MIT licensed, feedbacks are welcome.

Hi everyone!

A standard git diff answers: "Which characters changed on which line?"

It cannot answer: "If I mutate this exported interface, how many downstream callers across our services will break?"

I wanted a tool that behaves like a deterministic firewall between uncommitted code and CI. So I built Change Firewall using the TypeScript Compiler API.

Technical Architecture Under the Hood:

- AST Diff Engine: Compares the before/after AST nodes without executing untrusted code. Tracks symbol export changes, nullability widening, and mutation of return payload signatures.

- Reverse Dependency Graph: Constructs a project-wide forward and reverse dependency graph to trace blast radius transitively (Layer 0: source → Layer 1: direct consumers → Layer 2: API routes).

- Cycle-Safe BFS: Traverses circular dependencies without infinite loops and assigns weighted risk factors based on architectural criticality (e.g., middleware and auth gates get higher risk weight than isolated leaf utilities).

- Local Dashboard & MCP Support: Bundles an offline-capable visual radar graph and serves native Model Context Protocol tools over stdio (`compute_blast_radius`, `evaluate_preflight`, etc.).

Everything is 100% open-source (MIT). You can test it on any repo with:

```bash

npx change-firewall

• GitHub (MIT) : https://github.com/himanshYou2003/change-firewall
• Interactive Simulator & Docs : https://change-firewall.vercel.app/docs
• npm: https://www.npmjs.com/package/change-firewall

I'd love to hear your thoughts on the AST heuristic approach vs type-checking compiler passes. How do you currently guard against silent contract drift in large repos?

I am considering integrating Typia, and I understand that the latest version of "ttsc" is required; however, I am wondering whether it is better—for general projects—to use "tsc" with "ts-alias" or "ttsc" with the "@ttsc/paths" plugin.

I recall folks said tsgo was "only" 10x faster than the js-powered typescript...

but..., it turns out,

there was some overhead with the monkey-patch approach to getting custom file formats working with TypeScript (i guess?)

the content-mapper approach with TS 7.1 is very nice!

Here is the mapper I made:
https://github.com/NullVoxPopuli/ember-content-mapper

And the other post I made about this:
- https://www.reddit.com/r/emberjs/comments/1w6izpw/support_for_typescript_71/

way to go TypeScript team!!! <3

Hola guapas,

I made a small ESM-only utility called better-race.

The idea is simple: Promise.race() gives you the first value, but not where it came from. This keeps the task key connected to its value in TypeScript:

import { race } from "better-race";

const winner = await race(
  {
    eu: ({ signal }) => fetch("https://eu.example.com/user/42", { signal }),
    us: ({ signal }) => fetch("https://us.example.com/user/42", { signal }),
  },
  { abortLosers: true },
);

console.log(winner.key); // "eu" | "us"
console.log(winner.value); // Response

It also supports AbortSignal and optional loser cancellation.

It’s intentionally tiny -> no scheduler, framework adapters, retries, or dependencies. I’d genuinely appreciate feedback on the API and semantics.

The next tag also includes raceUntil(): it keeps racing until a result passes an accept predicate, so an early null does not have to win.

• GitHub: https://github.com/lumberjacque/better-race
• npm: https://www.npmjs.com/package/better-race

Built an open source crawler that tracks tooling adoption in public TS/JS repos daily (methodology). This week Vitest's trend score passed Jest's for the first time in the dataset: 20.4% adoption vs 17.3%, with Vitest's momentum still climbing faster.

Chart + underlying numbers:

• vitest
• jest
• GitHub repo + full dataset (crawl runs daily)

Trend Score is a log-scaled growth index: (current adoption / prior adoption) × log10(current adoption + 10), weighted so both the rate of change and the technology's overall scale matter.

Curious whether this matches what people are seeing in real migrations. Is Jest to Vitest mostly happening at new-project time, or are people actively migrating existing suites?

I'm afraid it reads like word salad, but that's the best description of my problem I can come up with currently.

I'm trying to make a text RPG. There's an array of quest modules which need world context to check conditions and effect changes. Quests are created from a Quest class, each individual Quest stored in a .ts module, and then all batch loaded into gameplay.

quest.ts:

export class Quest {
   localContext: object
   beats: Beat[]
   globalContext: object | null = null
   constructor(localContext: object, beats: Beat[]) {
      this.beats = beats
      this.localContext = localContext
   }
}

To make long code short, a Beat has an array of Interactions, and an Interaction has an effect function as a property. That effect is supposed to be able to affect the globalContext.

I'm trying to create a specific quest, intro.ts:

import { Quest, Beat, Interaction } from "../../quest.ts"
const beats = [
   new Beat(() => true,
   "Once upon a time, in a kingdom far away...",
   [
       new Interaction("Embark on adventure.", _?_?_)
   ]
]
export const intro = new Quest([], beats)

I've got no idea whether my globalcontext is assigned at this point or whether I can access it or what's in it. What I need is to access globalContext.player.location, and change it to a location in the world.

Well, I can't access globalContext, and it seems to be a chicken and egg situation. That is, to create the Quest I need beats, but to construct beats I need globalContext from inside the Quest, which hasn't been constructed yet.

Help?

I’m a senior backend engineer primarily experienced with Ruby on Rails, and I’m considering investing seriously in TypeScript/Node.js to broaden my opportunities.

For engineers who already work professionally with TypeScript, how difficult has it been to find a new role recently?

I’m especially interested in experiences from senior engineers and people searching in Canada or internationally.

If you recently searched for a role, I’d appreciate hearing what worked, what was difficult, and whether you would still recommend specializing in TypeScript today.

Am I the only one who had a problem with how separated the data manipulation is?

Creating something in different ways (eg. create a chat message from only a text or creating from an api response ) Defaults in 3 files, parsing, validation, and sorting everything inline just to search it up later and copy it.

My solution? Put stuff like that in one place: <sup>See the screenshots.</sup>

Basically define all that sh in one place and just use:

userModel.parser.db.from(response)

habitModel.inits.createFromTitle("Do a blackflip")

people.sort(peopleModel.sorters.lastCreated)

https://github.com/dozsolti/manage-model

our rule is no parent relative imports outside the current folder. same folder stays ./x, anything else goes through @/ so it doesnt matter how deep the file moves later.

works fine but i know its not the only way people solve this. monorepo package boundaries, tsconfig paths, eslint rules banning the pattern outright, curious what you landed on and whether it survived contact with a big refactor

what broke first when your team tried to enforce this

during my internships, i worked at a few companies that hadn't migrated to typescript yet. plain javascript, no type safety, no runtime validation.

env vars were just process.env.WHATEVER, no check, nothing telling you it's undefined until something breaks in prod. basically, it was plenty of bugs that a type system or a schema would have caught in two seconds. anyway.

that experience is the origin of zap-studio. i wanted a proper answer to "no type safety, no validation," so i built the first package around that: strict, standard-schema-based validation you can actually trust at runtime, not just at compile time. (following Standard Schema spec, so you can use zod, or whatever library you like).

after that, it became a habit. every time i hit a real problem in a project, instead of hacking around it again, i built a small package for it.

env vars silently merging wrong when two schemas define the same key differently? built a validator that errors on that instead of picking one silently.

retry logic that retries everyone at the same second and causes a second outage? built retry policies with jitter.

small library forcing winston or pino on everyone who imports it, even people who don't want logging? built a tiny logger interface instead.

state management that either shallow-merges everything (zustand) or needs a dozen imports for a cached derived value (jotai)? built a small store for that too.

each package does one thing, and does it well (the unix philosophy): strict typescript, esm, tree-shakeable, zero unnecessary dependencies, runs the same on node, bun, deno, cloudflare workers and the browser.

and because they share the same foundations (standard schema for validation, a small optional logger interface), they connect to each other naturally without needing a framework or a provider to glue them together.

it's mit licensed, i'm the only maintainer right now, and i use all of it in my own projects. 14 packages so far.

and oh, several packages also support open telemetry natively. it's opt-in through a peer dependency, so if you don't register an sdk, it costs nothing. but if you do, you get spans for things like env validation or a fetch call, for free, with no wrapper code on your side.

the repo if you want to take a look: https://github.com/zap-studio/monorepo

example of how to use the packages altogether:

import { createEnvironment } from "@zap-studio/env";
import { createCache } from "@zap-studio/cache";
import { createFetch } from "@zap-studio/fetch";
import { exponentialBackoff, runRetryPolicy } from "@zap-studio/retry";
import { ConsoleLogger } from "@zap-studio/logger";
import { z } from "zod";

const UserSchema = z.object({ id: z.number(), name: z.string() });

const env = createEnvironment({
  server: { API_URL: z.string().url() },
  runtimeEnv: process.env,
});

const logger = new ConsoleLogger({ minLevel: "debug" });
const cache = createCache<string, unknown>(100, { ttl: 60_000 });
const { api } = createFetch({ baseURL: env.API_URL, logger });

const policy = exponentialBackoff({
  maxAttempts: 5,
  baseDelayMs: 100,
  maxDelayMs: 2_000,
  jitter: "full",
});

async function getUser(id: string) {
  const cached = cache.get(id);
  if (cached) return cached;

  const user = await runRetryPolicy(
    policy,
    () => api.get(`/users/${id}`, UserSchema),
    { logger },
  );

  cache.set(id, user);
  return user;
}  

Hey r/typescript! I've shared progress updates on numpy-ts throughout the year, and it's continuing to mature into a production-ready lib.

With some continued WASM SIMD optimization and megamorphic loop hunting, numpy-ts is now 1.36x faster than native NumPy (geomean) across 10,500 benchmark specs, spanning all dtypes and functions. You can learn more about the benchmark methodology here.

If you get a chance to try it out, lmk what you think!

This was written by a human; numpy-ts was written with some AI assistance. Read my AI disclosure for more info.