plX allows you to write safe postgresql procedures in typescript that transpile down to plpgsql. It is open source and licensed under the MIT license.
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?
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:
where, select, …) just adds to a query plan. Nothing runs yet.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:
WHERE and a per-object "can this user see this?" check.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.
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?
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:
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?
Hi I want to make a career in tech industry. I am pretty sure I will start my career as a backend developer in this present scenario of job market. But I am in a doubt that Wheather to start with type script ecosystem with node js and nestjs or Python ecosystem with Django.and fast API backend..
The main reason I am still unable to choose because I want to do backend development but looking at present scenario and for future. I feel going for learning Python backend ecosystem will be good decision because Python can also give me the AI ecosystem so it will be backend plus AI integration. But also haven't seen any Python demand for backend development. The posting of python are of mainly towards AI engineer, data science and ml engineer.
What to do and which one to pick in this situation. So this is the main problem, please help me to figure it out ..
Please anyone can give their kind suggestions??
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 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?
Something I kept running into building agent tooling: giving an agent an MCP
tool that *could* answer a question about the codebase doesn't mean it will.
Tool-call decisions are probabilistic, not guaranteed. The agent has to
recognize it needs the tool, remember it exists, and choose to call it over
just grepping. A lot of "codebase context" products are architected as
exactly that: an MCP server sitting in the tool list, unused more often than
not.
Graft's bet is different: don't wait to be asked. It hooks directly into
Claude Code. The matching nodes get pulled into every prompt automatically,
editing a file surfaces its dependents inline, and the graph re-syncs itself
in the background after every edit, all without the agent deciding to invoke
anything. Same reason Chrome doesn't ship with an ad blocker built in: the
core stays general, and the extension handles the specialized job. Graft is
that extension for context.
Underneath, it's a typed graph, not a vector index: tree-sitter builds a
deterministic per-symbol graph (no model call), and an optional `--deep` LLM
pass groups that into markdown nodes with typed links (`depends_on`, `uses`,
`produces`) an agent follows like any other file. Method calls resolve
through the receiver's type (constructor assignments and type annotations,
not just call-site name matching), so a common method name doesn't pull back
every unrelated method with that name across the codebase.
The claim: up to 4× cheaper and 3× faster, with better or no loss of
correctness. Setup: 162 runs, two repos (graft itself + a real Node/Express
auth service), 3 trials each, single-file and multi-file questions split
evenly. Three variants of the same Claude Sonnet 5 agent: cold (explores from
zero), push (context bundled up front), pull (MCP tools, nothing injected,
paid for only when asked). A separate Opus 4.8 model graded correctness with
a required-keyword floor, so a fast-but-wrong answer couldn't win by being
fast. Cost is cache-aware (reads ~0.1×, writes 1.25×) to match real billing.
Results: push cut cost 32%, tool calls 46%, latency 60%, at equal correctness
(93% both, no loss). Pull gave up most of the speed but correctness jumped
to 98%, +5 over cold, the "better" half of the claim, and worth noting: pull
*is* the MCP-tool-list approach, and it still worked, because the harness
forced the call. Left to its own judgment across a real session, that's
exactly the discipline that erodes.
Second test, because a benchmark on questions can still be gamed: reset
PocketBase to its base commit before 5 merged PRs, re-implemented each with
and without graft, scored by file-overlap with what the maintainers actually
changed. 5/5 reproduced, at 21% lower cost.
Opensource, MIT licensed
Here's the repo link : https://github.com/NanoNets/Graft
I’ve been working on a project called TheScheme for managing how Codex follows rules inside a codebase.
TheScheme is the template behind everything. It defines how rules are written, how Codex routes between them, and how to stop a large set of instructions from turning into one huge prompt that gets partially ignored.
Instead of putting every instruction into "AGENTS.md", it uses a main router and smaller rule files. Codex starts with the router, works out what the task touches, and only loads the files it needs.
The first full ruleset I built with it is Pragmatic TypeScript. I’ve been using it with Codex on actual projects.
The basic TypeScript approach is:
"Type Strategy → Functional Core → Procedural Shell → Smallest Honest Boundary"
In practice, that means making the domain meaning clear in the types, keeping decisions separate from side effects, and not creating extra services or classes unless they own something real.
One of the main parts is a mirrored-type check that runs before and after changes.
Before editing, Codex checks the boundary it is working with and looks for an existing source of truth. That might be a Zod schema, a runtime object, a function return type, a generated Prisma or Drizzle type, an OpenAPI contract, or a handwritten domain type.
The check is light on purpose. It doesn’t force Codex to add more schemas, brands, helpers, or abstractions. It just makes it check what already owns the shape before creating another version of it.
After the edit, it runs a proper source-of-truth audit. That compares changed types against schemas, generated contracts, runtime values, factory returns, and existing exports.
For example, Codex might write:
type RouteName = "home" | "billing" | "admin";
const routes = {
home: "/",
billing: "/billing",
admin: "/admin",
} as const;
The audit can see that "RouteName" is just a second copy of information already stored in "routes", so the better version is:
const routes = {
home: "/",
billing: "/billing",
admin: "/admin",
} as const;
type RouteName = keyof typeof routes;
It does the same kind of check for interfaces that mirror Zod schemas, copied generated types, duplicated DTOs, and schemas where "z.input" and "z.output" are different because the data gets transformed.
It also understands that similar types can be intentional. A transport DTO and a domain model don’t always represent the same thing. Those cases can be left alone instead of being treated as errors.
The post-change audit separates actual problems, possible drift, acceptable choices, and the smallest useful fix.
The TypeScript pack also has routed rules for errors, Zod boundaries, async workflows, cancellation, workers, HTTP handling, database access, generated clients, functional core/procedural shell architecture, and anti-regression checks.
The other main part of the project is the Pragmatic Codex Schema Factory.
The factory takes the same Scheme template and uses it to build a Codex setup for another project. It isn’t a normal code generator. It generates the instruction and routing environment that Codex will use while working in that repository.
It can create:
AGENTS.md
.ai-rules/
.agents/skills/
.codex/
docs/
prompts/
templates/
The process starts with planner mode. Codex asks about the actual project before generating anything: the framework, database, validation approach, error handling, architecture, directory layout, naming rules, and other conventions.
It then produces a blueprint showing both the application structure and the proposed AI rules structure. Nothing gets written until that blueprint is approved.
Once it is approved, the factory compiles it into Codex-native files.
There are four main factory skills.
"$schema-architect" asks the planning questions and designs the blueprint.
"$schema-to-codex" turns an approved blueprint into "AGENTS.md", routed ".ai-rules", Codex skills, and optional ".codex" configuration.
"$codebase-schema-integrator" is for an existing repository. It inspects the repo first and plans where the rules, skills, and Codex files should go without immediately changing anything.
"$schema-auditor" checks an existing setup for duplicated rules, broken routes, missing triggers, context drift, and instructions that no longer match the project.
The point is to keep the human in the loop. The planner asks, the human approves, and then the factory creates the files.
So TheScheme is the reusable template, Pragmatic TypeScript is a working ruleset built from it, and the Codex Schema Factory is the part that can build the same kind of routed setup for other repositories.
Repo:
https://github.com/mayett515/TheScheme
Pragmatic TypeScript router:
Type source-of-truth checker:
Codex Schema Factory:
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?
This one took a while, it's probably the longest thing I've written on this blog. I wanted to do a proper end-to-end walkthrough of cmd/compile: real package names, real data structures, diagrams for the AST and SSA CFG, and the flags you actually need (-m, -m=2, GOSSAFUNC, -S) to observe each phase yourself rather than just take my word for it.
Covers the full pipeline: lexer → parser → type checker → IR lowering → SSA construction → optimization passes (inlining, escape analysis, BCE, nil check elimination, register allocation) → architecture-specific code emission.
Hope it's useful — happy to answer questions or push back on anything that looks wrong.
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"
}
Hello bro. I am in the last semester of my bachelors in Nepal .
I want to make a solid careers in tech industry.
I don't have any working experience or any deepen skill and what will be in the future ..
what would you recommend me to the sector and what actually the skills and technology you recommend me to learn in this situation demanded any employable in the industry ....I am thinking to start the learning backend development and for the backend development and confused what to use either node js , JavaScript/typescript ecosystem or python ecosystem with the django and fast API.... For the present condition And for future....
How to actually learn the new things and also how to adapt to the industries.... Please help me with your suggestion??