r/typescript

pnpm 11 feels like the first Node.js package manager update in a while that actually improves supply chain security by default.

Features like:

• minimumReleaseAge
• blockExoticSubdeps
• allowBuilds

directly reduce the risk of malicious package installs in CI/CD pipelines.

I wrote a short deep dive on why I think pnpm is now a better default than npm for production workloads.

Curious what others here are using in production today.

Fala pessoal,

Venho bastante do ecossistema Java e sempre gostei do estilo de trabalho do Spring Boot: DI, controllers, services, repositories, estrutura previsível e uma separação mais clara das responsabilidades no backend.

Ao mesmo tempo, também gosto bastante da experiência do NestJS no TypeScript. Só que usando Bun eu sentia falta de algo nessa linha que fosse realmente pensado para Bun desde o começo, e não uma adaptação de algo Node-first.

Por isso, nos últimos dois anos venho criando um framework para Bun + TypeScript para usar nos meus próprios projetos pessoais. A ideia foi juntar um pouco dessa organização do Spring Boot/NestJS com a performance e simplicidade do Bun.

Hoje ele tem core HTTP feito para Bun, controllers com decorators, dependency injection, middleware, validação com DTOs, lifecycle hooks, sistema modular/plugin-based, WebSocket, scheduler, queue com BullMQ, static files, logger e algumas utilities para testes.

Uma das partes em que mais trabalhei foi o ORM. Ele suporta PostgreSQL e MySQL, não usa Knex por baixo e nem depende de outro query builder externo. A camada de query builder/mapeamento foi feita do zero.

Ele tem repository pattern, active record opcional, migrations, relations, transactions, identity map, cache, optimistic locking, bulk operations e read replicas.

Também adicionei algumas ideias inspiradas em Spring Data, como derived query methods:

findByEmail(...)
findAllByStatusAndActive(...)
existsByEmail(...)
findTop5ByStatusOrderByCreatedAtDesc(...)

Não é uma tentativa de copiar Spring Boot inteiro para TypeScript, nem de substituir o estilo mais minimalista que muita gente gosta no Bun. É mais uma tentativa de criar uma opção para quem gosta de backend mais estruturado, com DI, módulos e uma camada de persistência mais integrada.

Eu já uso esse framework em produção em alguns projetos meus, mas ainda estou tentando entender se esse estilo faz sentido para mais pessoas no ecossistema Bun.

Para quem usa Bun em backend: vocês sentem falta de algo mais opinionated/estruturado, tipo Spring Boot ou NestJS, ou preferem manter tudo mais minimalista?

Também estou aberto a feedback sobre API, arquitetura, documentação e DX. Se alguém tiver interesse em testar ou colaborar, posso mandar o repositório nos comentários.

I was recently going through npmx and saw how it tells you the type information or the fact that you need an additional package for types for the package that you are about to install.

I was thinking, can there be a tool that can just detect that you are using TS so you'll need the types package and install it for you?

Would such a tool need hardcoding manually the various types packages associated with the JS packages or maybe is there some shortcut?

How do you deal with auto generated types coming from libraries you are using? The information on hover is very difficult for me to read/basically useless and I often end up going to look up documentation instead of just getting the info on hover.

I know there is pretty errors extension for errors, but is there anything similar for general types?

I'm building a speech to text API in TypeScript and I want to do the client SDK properly. Typed errors, clean method signatures, the whole thing. It's the kind of thing that's easy to rush and regret later so I'd rather have someone to think it through with.

The SDK would be the reference implementation. Other languages come after, handled by whoever knows those ecosystems. So getting the TS one right actually matters.

The rest of the project is a self hosted async server with a job queue. Not huge. Probably a few days start to finish.

If SDK design in TS sounds like something you'd enjoy, reply or DM me. Happy to share more details.

idk who thinks an AI could beat them, but that's the premise. show is called the ultimate coder on YT.

Open-sourced a TypeScript project that might be interesting from an implementation perspective: Git Faker 3000.

It is a Next.js app that lets you paint a GitHub contribution graph and push real backdated commits through the GitHub API. The whole thing is fully typed. The GitHub API client, the generation engine (grid math, PRNG, date utilities), the execution engine, session encryption, everything.

Key TypeScript patterns used:

• Typed REST API wrapper with pagination and error formatting
• Strict input validation with regex patterns for owner/repo/branch names
• Discriminated unions for execution states
• Generic API route handler patterns with JSDoc headers

11 API route handlers, zero any types, zero shell execution.

MIT licensed.

https://github.com/Spielewoy/git-faker-3000

Star the repo if you want to see more of this kind of thing.

hey to everyone,

This open-source tool recently reached 1K GitHub stars and around 12K installs. Sharing here in case its useful to other TypeScript devs. It’s fully free and open source.

Its an offline API devtool and what is special about it is that requests live as executable markdown and are versioned in Git. 

Just to give a bit of a background, the inspiration is Obsidian-style files and curl. As opposed to to other tools I have used, everything in Voiden can be composed with blocks (endpoint, auth, params, body) that can be added, reused, overridden, and stitched together across executable markdown files. 

Since open sourcing, got a lot of feedback, ideas and contributions and most of the stuff added comes from this feedback: chaining requests, scripting, and structuring everything into reusable .void files. So mainly workflow stuff. The next big item we are looking to add is the CLI runner (maybe its one one of the things I hear more).

A bit of context for the workflows:

Scripting: I want to highlight this one cause in other API tools scripts live in a constrained JS sandbox. In Voiden nope. Since it runs locally, we were able to flip that and allow scripts to run in real runtimes: JS, Python, shell (and will add more).

Multiple requests per file (mini workflows): Putting multiple requests in a single .void file was an idea from a user. You can group full flows together (create-pay-confirm), or full CRUD cycles. The file becomes an executable workflow where docs and tests live together naturally, and you can run one request or the entire sequence end-to-end. 

Stitch (workflows across files): This is our take on the collection runner. Workflows (“Stitch”) are built from .void files that you can combine across scenarios. You define small flows (auth, setup, CRUD, etc.) and stitch them together into larger workflows (without duplications).

Agents: Added “skills” so Claude or Codex agents can work directly with .void files using your own environment and subscriptions. Yeah, one of the perks of everything being file-based and Markdown-first. 

+ We also built an SDK for community plugins and spent time improving performance, reliability, and keyboard-first DX (Electron-based, so we have been careful there).

For those that work with Postman or Swagger I wanted to make it easy to import and try this: https://docs.voiden.md/docs/getting-started-section/getting-started/postman-import/

Looking for feedback and ideas from anyone interested.

Github: https://github.com/VoidenHQ/voiden

Download: https://voiden.md/download

https://i.redd.it/om296279r21h1.gif

What is the proper way to do that? I got a big monorepo of various .ts scripts that share imports, that's why I put them in the monorepo but I don't want or need to upload the entire repo to the server when I only want to run one of the .ts files with pm2.

What are my options? I don't want to manually find all the imports and dependencies and upload .ts file to be run with tsx. That sounds like too much manual error prone work.

If I transpile only a single .ts script into a .js script, can I get any kind of CLI option to output some kind of a external dependency list?

If using esbuild, how do I know what needs to be excluded and installed manually on the server? Figure it out by trial and error?

A few things were annoying me with how Effect code is written so I wrote some utilities to improve the experience. For anyone who writes Effect code I'd appreciate some feedback on the library and article if you have some time. I have some feedback for the Effect maintainers regarding how Effect should evolve.

TL;DR: rather than writing

const someEffect: Effect<void, SomeError> = Effect.gen(function*() {
  ...
});

write this

function* someEffect(): Effect.fn.Return<void, SomeError> {
 ...
}

you'll get more targeted error messages from the compiler.

I know everybody hates AI-generated posts but that also means that you have to handle my writing being non-native english and neurodivergent :D

So this is a project I spent most of my free time on in the last 8 months after I started mcp-funnel (https://github.com/chris-schra/mcp-funnel, now rather obsolete) - I was thinking that it should be .. well... helpful at least... to create a "thing" (tooling, framework, ecosystem, no matter how you call it) to connect typical components involved during "AI-assisted engineering". And this led to the Makaio Framework: https://github.com/makaio-ai/makaio-framework.

I'm intentionally posting here in r/typescript first (instead of any AI-related subs) because I'm most interested in your thoughts about the general architecture and abstraction. Note that this is really solely about the architecture - I won't even guarantee that the codebase is runnable in other environments than my machine and CI :D (although I pretty much think so). And it's code-first, no packages published yet.

Here are the "edges" I think that are most relevant for TS devs:

• Schema-first: Zod is the definition layer - Bus subjects, CLI args, tool I/O, storage schemas, extension config... all flow from Zod schemas. Types are z.infer<>, no parallel maintenance. Comparable to tRPC-level type safety, but for a full event bus. (see https://github.com/makaio-ai/makaio-framework/blob/develop/docs/bus/index.md )
• Compiler as architecture guardian: The event/request split, namespace scoping, and local/channel subject routing are encoded in the type system. Wrong usage doesn't compile. (see, for example, https://github.com/makaio-ai/makaio-framework/blob/develop/docs/bus/decoupling.md )
• Multi-tier abstraction with type safety: The adapter contract is three layers deep: AIAdapter<TBus, TConnector, TAgent> → AIAgent<TBus, TConnector> → AIAgentConnector. Each layer is ndependently swappable (new connector for an SDK update, new agent for different orchestration) and TypeScript generics enforce correct composition at compile time. Wiring the wrong connector into the wrong agent is a type error, not a runtime crash. A shared conformance test suite then verifies that the type contracts also hold semantically: consistent streaming, tool approval, and error handling across 9 adapters (Claude, Gemini, Codex, GitHub Copilot, Qwen). Cross-language SDKs (Python, Rust, TS) share wire-level conformance fixtures.
• Maybe you might find the "code policies" interesting - I tried to build some guardrails supporting "AI-first engineering" (while avoiding slop) by creating custom test reports and a custom validation script (token-optimized and - hopefully - AI- and at the same time human-friendly rules) (https://github.com/makaio-ai/makaio-framework/blob/develop/scripts/validate.ts)

Stack:

• Well, Typescript :D Zod (v4), Drizzle (sqlite), Vitest, Node & bun (adopting bun more & more)
• Claude Code for planning, human for "coding the foundations", reviewing and fixing (most of) the slop, Codex (and Coderabbit) for review
• Electrobun for (minimalist) GUI (I like it so far - but still plan to keep feature parity with the parallel Electron GUI.. just in case)
• Starlight with some handmade extras for "website" https://makaio.ai
• Cloudflare Snippet in a desperate experiment (not working yet) to render markdown instead of HTML from docs - I tried rewriting URLs for AI "user-agents" from, e.g. makaio.ai/why to makaio.ai/why.md based on their "Accepts: text/markdown"-header (which they don't seem to send yet, obviously. Narf.)

Seriously, feel free to downvote and share you thoughts (including the negative ones) but PLEASE keep in mind: I really put a lot of effort (and heart & cognitive capacity) into this ;)