Daniel Sanchez

Building agentic apps? Use TanStack Start for full-stack delivery, TanStack AI for type-safe tool calling, and TanStack DB for live incremental queries + optimistic mutations. Add PowerSync for offline-first sync, and your app keeps moving even when the network doesn’t. Build for the PowerSync AI Hackathon and compete for cash prizes plus an hour of @tannerlinsley's time and some amazing @tan_stack swag!

The new PowerSync Dashboard, powered by @tan_stack Router and Query, is now featured on the TanStack Showcase! As the PowerSync Dashboard grew with complexity and requirements, @tan_stack Router scaled with it beautifully. Fully type-safe, flexible, easy to migrate to, and great features like type-safe search params and query prefetching.

Drizzle Studio now has query telemetry 🚀 - connection overhead with DNS lookup, TLS/SSL/TLS and database handshake (on/off) - latency to your database (on/off) - query itself with planning, execution, download and parse time As of now we support Postgres and MySQL, but we will cover every driver/dialect! install `drizzle-kit@beta` tag

How do you set up monorepos and keep TypeScript fast, without requiring local builds all the time? I'm very confused! Let's say you are building a monorepo with multiple packages, and an example app within the monorepo that consumes the packages. The packages have a build step for publishing, and each package defines their `exports` in package.json. I see these options: 1. Do nothing. Just `tsdown` to build packages and d.ts files on every change. This is simple, but slow for development. `--watch` could work, but I've run into issues doing `pnpm -r build --watch` where it was only rebuilding a subset of packages each time. I'd much rather just have my devserver take care of this for me than running yet another tool locally. 2. Use a "development" condition for source files, and set Vite and TypeScript to resolve "development" in dev. This way you don't need to build during dev, but you also need to ship the source files to npm, otherwise tooling will fail looking up "development" conditions pointing to missing files in production. 3. Use resolver aliases for each tool: Similar to the development condition, without the production downside, but somewhat annoying to manage a list of aliases for each tool. In my experience, when using aliases heavily, there will always be tooling problems since they don't all support aliases, or have different config etc. I guess Vite 8's tsconfig support simplifies this a bit, but that's opt-in for now. For all three, TypeScript checks something different. In some versions it checks the source, and the compiled output in others. If you only check the source, you can't guarantee that the published package's types will be correct. Nothing will stop you from publishing packages with missing types, unless you set up yet another CI job to check for this specifically. If you only check the compiled output, you have to build it all the time during development. How do you handle this for a repo where some packages are published and some are not? Yet another solution could be to compile a project into `src` for publishing as well, so that `exports` are the same for development and published packages. That way no special config is needed. It requires a bit of custom setup for publishing, though. Examples: * fbtee.dev at github.com/nkzw-tech/fbtee currently requires `pnpm build` each time a package is changed. * fate.technology at github.com/nkzw-tech/fate currently uses aliases for Vite, but requires a `pnpm build` for TypeScript when the public interface of a package changes. * Athena Crisis at github.com/nkzw-tech/athe… just uses everything from source as the packages are not published to npm. However, inevitably, with any of the three solutions, tools will become slow as the repo grows. Now what do you do? `isolatedDeclarations` + checking in d.ts files for each repo? A `tsconfig` for each package, which makes everything even slower since TypeScript will now do overlapping typechecks across your project? Then paper over with Turborepo to make it feel ok? I think Project References in TypeScript are supposed to be the solution, but somehow that hasn't worked well for me and hasn't sped up TypeScript that much. What do you do? What do you suggest? What am I missing?