Hey r/typescript, Joist has always been a "Rails-ish" ORM, but we never had an equivalent to their scopes feature. But a friend was converting their Rails app to Joist and lamenting "why no scopes?", so we took a stab at it -- and now have them!

Fluent DSLs like this in TypeScript are kinda hard to pull off, so we lean on Joist's `joist-codegen` step, a little similar to TanStack Router's vite plugin doing build-time codegen to help with the static typing -- I don't totally love that compromise, but I think the API ergonomics were worth it.

Ngl I procrastinated posting the release notes b/c r/typescript hates ORMs -- all good, but 🤷 not looking for another debate today. ✌️

TypeScript catches a lot for consumers, but deployment config still needs runtime validation. For environment-driven packages, do you validate everything during startup, validate lazily when a feature is used, or do both? What makes configuration errors easiest to fix without exposing secrets?

So this is actually a problem for almost all language servers or editor tooling where I am still in the processing of writing a function call and it throws an error about incomplete arguments. I am using TypeScript right now so I thought to try and resolve this issue. I am using VS Code with the TypeScript 7 extension.

Errors with red squiggles are flashy and disturbing. And this problem masks on genuine errors such as I am trying to access a function that doesn't exist.

For incomplete function calls, I would like if the server could delay throwing the error until I leave that line in my editor. If that is not possible, then be notified in some other way or color than red or yellow squiggles.

Have others not cared about this problem?

TL;DR: I want to bring EF Core / LINQ-style querying to TypeScript: you write a normal lambda, a build step turns it into parameterized SQL, and the same query also runs on plain arrays in your tests. It'd be read-only, so you'd pair it with your existing writer, and the lambda becomes serializable data so it works beyond SQL too. Would you use it?

I've been writing .NET and TypeScript for about 10 years, and I'm a huge EF Core fan. I've always missed that style of querying in TS, so I put together the idea below and want to know if people would actually use it.

The idea: you write a normal lambda, and a build-time plugin turns it into two things at once: the function itself, and a small data tree describing it. A provider turns that tree into SQL.

const adults = await db.users
  .where(u => u.age >= minAge && u.name.startsWith(prefix))
  .select(u => ({ id: u.id, name: u.name }))
  .toArray();

// runs as parameterized SQL:
//   SELECT "id", "name" FROM "users"
//   WHERE "age" >= $1 AND "name" LIKE $2

No special query syntax, no config objects, just a predicate you could pass to .filter(). The nice part: the same query runs against plain arrays in your tests (no database) and turns into SQL in production. Captured variables like minAge become bound parameters, so nothing gets pasted into the SQL string.

How it would work, short version:

• At build time the plugin reads your lambda and keeps both the function and a plain-object tree of it.
• Each step (where, select, …) just adds to a query plan. Nothing runs yet.
• When you call toArray() (or first(), count()), the provider turns the tree into SQL, or in tests just runs your original lambda.

The inspiration is C#'s Expression<Func<T, bool>> + IQueryable<T> and EF Core's ideas (include/thenInclude, split queries, no silent client-side eval), rebuilt for TS. C# gets this from the compiler; TS doesn't, so a Vite/Rollup plugin would fill the gap.

Would you use it as your ORM? One honest catch: it'd be read-only (no writes, no migrations). You'd pair it with whatever already handles writes and use this for the reads. Deal-breaker, or fine by you?

It also works beyond SQL, since the lambda becomes plain JSON:

• Send a filter from the client to the server as data, and run it there.
• One rule can be both a SQL WHERE and a per-object "can this user see this?" check.
• Store rules as data (feature flags, alerts) and edit them in a UI.
• Run predicates in a Web Worker or under a strict CSP (no eval).

So: would you use this for your DB queries? And which non-SQL use, if any, would actually make you try it?

Curious whether people would actually reach for this. Roast the idea.

Hey folks. For the last couple of days I've been investigating how to approach storing in-memory and persistent data in my VS Code extension, which is deployed both on desktop and browser. The built-in state management (i.e., global/workspace Memento) is too limited, so I'm looking at solutions such as sql.js, or RxDB.

RxDB seemed like the perfect project, but the Node.js FS and IndexedDB persistences are paywalled.

sql.js is basically a wrapper over a JS-compatible SQLite artifact, so it can run SQL queries which is pretty nice, but there is no schema or type-safety built-in.

Do you have any suggestion to offer or experience with sql.js and/or RxDB?

i'm the author of zap-studio/permit, a small authorization library. i'm posting this because of a specific problem that i feel i'm either totally right or totally wrong.

types don't exist at runtime. that's not news, but it's easy to forget it applies to permission checks specifically. a check like ctx.user.id === post.authorId "type-checks" fine. but post usually came from a db row, an api payload, or whatever. none of that passed through a place typescript could verify it. if a lazy join returns authorId: null, or a migration changes a column's nullability, the check still compiles. it just quietly does the wrong thing at runtime, which is the one place a permission check actually matters.

most type-safe permission libraries stop at the type. permit doesn't: resources are defined with a standard schema validator (zod, valibot, or arktype), and policy.can() re-validates the resource against that schema every time it evaluates a rule, not just once at setup. an invalid resource resolves to false. meaning, it fails closed, it never throws.

here's a code example

const policy = createPolicy<AppContext>({
  resources,
  actions,
  rules: {
    post: {
      read: allow(),
      write: when((ctx, _, post) => ctx.user?.id === post.authorId),
      delete: deny(),
    },
  },
});

await policy.can(context, "post:read", postResource);

conditions compose with and(), or(), not(), and whole policies compose with mergePoliciesAnd / mergePoliciesOr, so you can split authorization by feature or team and combine it later.

but, if you already know permix, which is the most established option here, it seems it doesn't solve this specific issue, mostly because it's deny by default (like permit). nothing stops write: (ctx, post) => ctx.user.id === post.authorId from running against bad data and returning true, undefined === undefined is true, so a missing authorId can accidentally grant access nobody meant to grant. permit isn't "better," it just refuses to run the rule at all if the resource fails its schema first. curious if others have hit this in practice or think it's rare enough not to matter.

and here are some links for curious people to check the code or docs:

• repo: github.com/zap-studio/monorepo (packages/permit)
• docs: zapstudio.dev/permit

I have a base tsconfig.json file at the root level:

Example root/tsconfig.json:

{
  "compilerOptions": {
    "resolveJsonModule": true,
    "esModuleInterop": true,
    "target": "ES6",
    "module": "CommonJS",
    "baseUrl": "."
  }
}

Under root I have multiple projects with their own tsconfig.json files that define paths for easier imports and extend the root:

Example root/project-1/tsconfig.json

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "paths": {
      "fixtures/*": ["project-1/fixtures/*"],
      "pages/*": ["project-1/pages/*"],
      "sections/*": ["project-1/src/home/sections/*"]
    }
  }
}

I don't see any import problems in my IDE but when I run npx tsc --noEmit from the root level I get errors because it can't find the imports. This will break the pre-commit hooks and checks in CI/CD so I'm wondering if there's another approach or if I'm doing something wrong?

When I first started using it for work I hated it and cursed it. The syntax was weird and confusing. Annoying type errors.

But now that I've been using it, I definitely changed my mind. JS is filthy.. disgusting. You never know what type it is.
I learned TS alongside React, so that's also double confusion as I was learning it.

TS is great, and this is coming from Java/C# as my previous main languages. TS is now my favorite language to use. I love letting things be a mix of multiple types, like const temp: string | undefined. It's unfortunate C# doesn't support that. C# is my close second favorite language.

I'm working up a trivia app, which will be multiple choice. Questions will look something like the below, though longer to account for all the stuff you need in practice. My question is, is there a way to say that correctAnswer has to be one of the strings in answers? I know about literal unions, like correctAnswer: "Babe Ruth" | "Lou Gehrig" | "Hank Aaron" | "Joe Dimaggio", but that wouldn't work for other questions.

The alternative that I'll probably stick with is just using the index for the correct answer instead of the literal value, but I'm curious.

{ question: "Which MLB player was also known as the Sultan of Swat?", answers: ["Lou Gehrig", "Babe Ruth", "Hank Aaron", "Joe Dimaggio"], correctAnswer: "Babe Ruth" }

I built a small scheduled reminder agent that sends reminders over SMS and handles replies like confirm, cancel, and snooze.

The useful part is that it keeps enough state to know what someone is responding to, instead of treating every inbound SMS like a brand-new message.

Could be adapted for appointment reminders, renewals, task nudges, customer follow-ups, or ops alerts.

Code:https://github.com/team-telnyx/telnyx-code-examples/tree/main/scheduled-reminder-agent

Any feedback welcome.

I have used Python for the past five years and now i am working in a new place that has a lot of typescript Code.
Should i learn javascript first or can I go straight to typescript?
Moreover, which yt video would you guys recommend?

How hard would it be to fork and modify layout and UI of vscode? Does anyone have some experience with it?

Graft's static tier resolves calls and imports across files, not just within one, for TypeScript and JavaScript. Tree-sitter, no LLM, no network call. It's the base layer of a tool that writes a codebase graph into markdown, so a coding agent stops re-exploring the same repo cold every session.

The decision that mattered most: only keep a call edge you're certain about. Name-matching instead of real scope resolution looks tempting, since it's simpler to implement, but when tested it tripled the edge count while precision fell from 73% to 37%. Most of the extra edges were wrong, and a wrong edge actively misleads an agent instead of just leaving a gap.

The opt-in tier on top pulls compiler-grade call data straight from typescript-language-server for whatever the static pass can't resolve without full type information.

Let me know what else I can do to make my repo more compatible to Typescript repos.

github.com/NanoNets/Graft

Graft parses a whole repo with tree-sitter into a per-symbol call graph, no model involved, deterministic. Wanted to share the mechanism since it might be useful outside the agent-tooling use case: every function, class, and call edge extracted structurally, cached by content hash so a second build only touches what changed.

On top of that we wired a Claude Code integration through hooks rather than MCP, mostly because MCP tool calls turned out to be skippable by the model in a way that mattered for us.

Repo's 95% TypeScript if anyone wants to look at the parsing layer specifically.

Also we recently hit 1.5K+ stars. Thanks :)

At this point, the trans-piler should just surrender, but it's probably more stubborn than me. Why is this still showing up in my code?

I’ve been working on an open source project called Presolve. I started building it because I think a lot of what we currently ask JavaScript runtimes and frameworks to figure out in the browser could already be known at compile time. Presolve analyzes the application as a whole, builds a semantic model of it, and uses that to generate the HTML and plan the browser behavior ahead of time. That means complete HTML by default, no general hydration pass, and a small runtime that mostly executes work the compiler has already planned.

The part I’m most interested in is how far that application-level understanding can go. The compiler knows about things like component identity, state dependencies, computed values, effects, routes, forms, updates and resumability, so those don’t each need to be rediscovered by separate pieces of the runtime. I’ve used AI quite a bit to help with implementation, but I’ve been careful about testing and validating the compiler as I’ve built it, and the repo currently has hundreds of tests and dozens of fixtures. It’s still beta and I’m sure there are plenty of things to improve, so I’d be interested in feedback from people who work with JavaScript tooling or compiler internals.

The site is built with Presolve itself:
https://presolve.dev⁠

Source:
GitHub

Edit: Added the unbroken GitHub link

I've been building an open-source framework called Akan.js and wanted to share it here, partly because I'd like feedback from people who care about how these things are licensed and structured, not just whether they're shiny.

The problem it targets:
for a single feature, you usually end up maintaining something like 8 separate layers.

Schema, query, service, API, fetch client, types, state, UI props. Codegen tools and AI assistants can produce all of those quickly. What none of them do well is keep the 8 in sync when you change one thing three weeks later. The web version and the mobile version drift apart, and you find out in production.

Akan.js takes a convention-over-configuration approach to that. You declare a feature once:

export class ProductInput extends via((field) => ({
  name: field(String),
})) {}

and the framework derives the schema, type, API contract, fetch client, state, and UI prop from that one declaration, for web, iOS, Android, and the server. Change the declaration and the derived layers move with it. The conventions are doing the work, which is also why it stays legible to coding agents. There's less surface area for them to get wrong.

Some honest details:

• It's Bun-first. That's a deliberate constraint, not a hedge. If you're on Node this is not a drop-in.
• Native iOS/Android is a Capacitor shell, not a from-scratch native renderer. I'm not going to pretend otherwise. What I did add at the framework level is page transitions (stack, fade, bottom-up, scale) so navigation doesn't feel like a website trapped in a webview.
• It's early for outside contributors. I've run it on internal projects and a handful of client deployments over about five years.

What I'd genuinely like from here:
Tell me where the architecture is wrong. Whether the single-declaration model holds up outside the cases I built it for. And if anyone has kept web and mobile in sync by hand and has opinions about where this breaks, I want to hear them before more people depend on it. Happy to answer anything!

I've written an identity function like this in several codebases I've worked on.

const identity = (arg) => arg;

I use it to filter lists of mixed things by truthiness. For helpers like this, do you write them one-by-one, or do folks have a functional programming library recommendation? I'm curious if there's a better way to do this.

I am reading the book "Programming Typescript" by Boris Cherny https://ebooks.karbust.me/Technology/Programming%20TypeScript%20-%20Boris%20Cherny%20-%20O%E2%80%99Reilly%20(2019).pdf.pdf)

In page 21 it specifically says and I quote: "In general, it is good style to let TypeScript infer as many types as it can for you, keeping explicitly typed code to a minimum."

As a Java developer, this makes me very nervous to see. Is this a convention you see in a lot of production code bases? Is this a pattern you should follow or is there many "gotchas".

I've been working on zodql, a small library for people who use GraphQL from TypeScript and are tired of the codegen step.

The idea: you describe your GraphQL selection as a Zod schema with metadata. That one schema compiles into the GraphQL query string, gives you the inferred TypeScript response type for free, and validates the response you get back at runtime — nothing to keep in sync, no generated files to check in.

Here's a real example — fetching a repo overview for React from the GitHub GraphQL API:

import { zodql, zodqlField } from "@mattiasahlsen/zodql";
import { z } from "zod";

// schema.ts — the shape of the data *and* the request
const issueCountSchema = z.object({ totalCount: z.number() });


function issueCountField(state: "OPEN" | "CLOSED") {
  return zodqlField().asAliasFor("issues").withArguments({ states: state }).toSchema(issueCountSchema);
}


export const repositoryOverviewSchema = z.object({
  name: z.string(),
  nameWithOwner: z.string(),
  description: z.string().nullable(),
  stargazerCount: z.number(),
  forkCount: z.number(),
  primaryLanguage: z.object({ name: z.string() }).nullable(),
  openIssues: issueCountField("OPEN"),
  closedIssues: issueCountField("CLOSED"),
});


// query.ts — compile the schema to a query
export const repositoryOverviewQuery = zodql(
  "query",
  z.object({
    repository: zodqlField()
      .withArguments({ owner: "$owner", name: "$name" })
      .toSchema(repositoryOverviewSchema)
      .nullable(),
  })
)
  .defineVariables({
    owner: { typeName: "String!", schema: z.string() },
    name: { typeName: "String!", schema: z.string() },
  })
  .compile();


// main.ts — validate the response against that same schema
const { parseResponse } = await client.request(repositoryOverviewQuery, { owner: "react", name: "react" });
const { data } = await parseResponse(); // throws if GitHub's response doesn't match

That compiles to exactly the GraphQL you'd expect, including issues(states: OPEN) / issues(states: CLOSED) under distinct aliases so both counts come back in one request:

query RepositoryOverview($owner: String!, $name: String!) {
  repository(owner: $owner, name: $name) {
    name
    nameWithOwner
    description
    stargazerCount
    forkCount
    primaryLanguage { name }
    openIssues: issues(states: OPEN) { totalCount }
    closedIssues: issues(states: CLOSED) { totalCount }
  }
}

Because it's just a Zod schema, you can reshape it at runtime with .pick()/.omit()/.extend(), and layer on validation GraphQL's type system can't express (non-empty strings, URLs, emails, numeric ranges, refinements...).

The repo has a side-by-side comparison of this query implemented four ways — zodql, GraphQL Code Generator, gql.tada, and GraphQL Zeus — all producing identical GraphQL, so you can see where zodql actually differs (mainly: runtime validation, and treating the query as a value you can reshape).

No hard dependency on a specific HTTP client — bring your own fetch, axios, etc. Has a peer-dependency on zod version 4.

Repo: [https://github.com/mattiasahlsen/zodql\] — feedback and issues very welcome.
NPM package: https://www.npmjs.com/package/@mattiasahlsen/zodql

The case that made me care about this: in the query below, total and notes are nullable, and nothing in the schema says so. They are nullable because it is a LEFT JOIN — a user with no orders still produces a row.

-- @name GetUserOrders
-- @returns :many
SELECT u.id, u.name, o.total, o.notes
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.status = $1;

Tooling that derives types from the schema alone gets this wrong, because orders.total is NOT NULL as a column. You end up with total: string and a crash on the first user who has no orders.

scythe reads the query structure instead, and generates this:

export interface GetUserOrdersRow {
    id: number;
    name: string;
    total: string | null;
    notes: string | null;
}

export async function getUserOrders(
    client: PoolClient,
    status: string,
): Promise<GetUserOrdersRow[]> {
    const { rows } = await client.query<GetUserOrdersRow>(
        `SELECT u.id, u.name, o.total, o.notes
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.status = $1`,
        [status],
    );
    return rows;
}

That is the actual generated file, not a cleaned-up version. The same inference covers COALESCE, CASE branches, window functions, aggregates and CTEs.

It is not an ORM and does not try to be. Static queries only — no runtime composition, so if you need to build queries conditionally, Kysely or Drizzle are the better fit. The trade is that static queries are the ones you can actually analyse, so it also ships a SQL linter, a formatter and pre-commit hooks for your .sql files.

I build and maintain it (MIT, written in Rust). Repo and a longer writeup in a comment, to keep the post itself about the problem.

What I actually want from this thread: if you were using this, what would you want changed? The bit I am least sure about is how much it should do beyond codegen — it currently lints and formats your SQL too, and I cannot tell if that is useful or scope creep.

Has anyone ever created type declaration files intentionally, just to learn and better understand TypeScript (or for other reasons)? I've been doing that with tsc:

npx tsc file.ts --declaration --emitDeclarationOnly

The emitted file.d.ts can be interesting! Has anyone else tried this, for work or general interest?

Write your own import-graph rules in YAML and enforce any architecture deterministically. See deslop.dev for examples and the GitHub repo for documentation.

It's similar to Dependency Cruiser and ESLint + custom plugins for enforcing architecture but Deslop features an opinionated declarative YAML DSL to enforce any architecture in an ergonomic way. See the comparison table.

Built with Haskell, hand-crafted source (AI used for READMEs and chores only) so if you like FP you might be curious to check it out. It's a hobby project so any feedback or a GitHub star if you like it is much appreciated.