Monorepo mandatory ?

[vjau]

I have a single page app which i wrote with three main repos (plus some other private dependencies):

• one repo for the rest api server
• one repo for the react client
• one repo imported by the two previous for code shared by the server , the client, and another related SPA project.

I would like to try trpc to be able to secure my api on the type front (i'm currently not enforcing api typing with a single definition but would like to do so).
I fail to see how i can share typings between the trpc server and the client if i'm not using a monorepo since the typings are defined by the server (if i understand correctly).
Does it mean a monorepo structure is mandatory if i want to use trpc ?
Thank you.

[KATT]

Either you do monorepo or you do some other ways of sharing types from the server like having an npm package for the server. I'm bullyish on monorepos in general so I can't give you much guidance

[krank56]

I second, monorepos are awesome

[masterbater]

So making the api as npm package and install it, the types will work? Sorry for my dumb question Im still learning about trpc and typescript in general

[KATT]

Further: #1860 (reply in thread)

[dohaicuong]

Just wonder for the use case of sharing types, will trpc have a way to build the types artifact that make this workflow easier to work with?

I'm currently trying to explore this workflow and it's pretty hard trying to building types only packages out of the service especially when I'm using together with prisma generated types.

On the side of generated types artifact, I can see https://rspc.dev/server/router#exporting-the-typescript-bindings, which is basically trpc for rust do it and it generate out a schema that allow for easier sharing

export type Procedures = {
    queries: 
        { key: "posts", input: never, result: Array<Post> } | 
        { key: "version", input: never, result: string },
    mutations: 
        { key: "postCreate", input: PostCreateInput, result: Post },
    subscriptions: never
};

export interface Post { id: string, title: string, content: string }

export interface PostCreateInput { title: string, content: string }

[hems]

Just wonder for the use case of sharing types, will trpc have a way to build the types artifact that make this workflow easier to work with?

indeed it would be good to generate those artifacts for instance if you want to share with other people / other projects / other repos

[bradennapier]

@KATT Monorepos ofc agree, that is not always a reality for some. Which makes tRPC a no-brainer for new projects, but to allow adapting to a wider community of those of us where architectures don't support such an environment ;-).

This could be implemented with a compiler transformer. Some things to solve ofc... but It is worth pointing out because I have actually built one for zod a couple years ago 🥇 . It was just a Proof of Concept for the zod community, but It would essentially transform a zod input validator into typescript types which could be easily communicated across repo-lines I would imagine.

I can only imagine what capabilities a ts compiler plugin could do for tRPC where essentially every part of the request would be exposed to transform however needed.

• Current thinking would be that it would generate a trpc dependency override similar to how Sequelize and sequelize-typescript currently require you to define manually - but could be automatically built and updated by expanding the right typescript interface.
  • Could be eslint-plugin, IDE Plugin, whateverPack plugin , or others
• Current little proof of concept was very crude and would need a lot of work - but it would be a possibility to make it more universally compatible.
  • Probably some fixes to make it 4.8+ compatible but those are fairly minor if needed.
  • Transformers working in your project can be difficult and requires either patching the ts runtime or using something like ttypescript --
    • This is why I specifically implemented it as a VSCode Extension so it could do it on command for the user rather than needing a transformer plugin or any compile-code setup
    • a client-side eslint plugin may be useable to automatically transform zod inputs copied from the server into typescript types instead that could be ingested or expanded. This can access the ts compiler and is quite straight forward
    • Just a wacky solution and concept :-P but it could potentially work and have a positive result on performance. Obvously quite a lot to make it work though

Shown is Type to Zod but it also did the opposite if I remember (or it'd be easy enough to do if i hadn't implemented that yet lol)

@dohaicuong this would actually probably be similar to how Rust is doing it, as I am sure that does some sort of compiler extension to generate rust code from the AST.

[KATT]

#1860 (reply in thread)

[ShunyaWatanabe]

I tried generating a TS declaration file to share TS types with other projects, and it seems to be working properly.

1. On backend, generate a server.d.ts file. (Replace server.ts with wherever you are exporting trpc's router type.) Keep in mind that the below command may need to be modified slightly for it to work on your project.

npx tsc --declaration --strict  --pretty server.ts --out server.js --emitDeclarationOnly

2. On frontend, copy and paste server.d.ts and import it like below (Make sure to install @trpc/server for frontend as well)

import { createTRPCProxyClient, httpBatchLink } from "@trpc/client";
import type { AppRouter } from "server";

const trpc = createTRPCProxyClient<AppRouter>({
  links: [
    httpBatchLink({
      url: "http://localhost:3000/trpc",
    }),
  ],
});

I also think it'd be great if trpc implements a functionality for generating a type file, instead of having to do the above.

[ElMatella]

Hey, I was also looking for a solution like this. But I'm wondering, with your solution, if all my types are in server.ts that would work, but what if I have a larger project, with imports everywhere, I should then copy and paste all the declaration files right? Wouldn't this be a security concern over server types implementation that don't fit strictly into trpc output? Like some interfaces that really don't have any relation with trpc output, can you see what I mean?

I think what we would need here would be a feature similar to Graphql introspection query right?

[ShunyaWatanabe]

if all my types are in server.ts that would work, but what if I have a larger project, with imports everywhere, I should then copy and paste all the declaration files right?

The command should only create one declaration file. Or did you mean you have multiple AppRouter types?

[ffxsam]

Quick note:

Add --lib esnext,dom to @ShunyaWatanabe's tsc command above for it to work properly.

[ffxsam]

BTW, I have a folder that contains client.ts and server.d.ts, and the following import gives the error "Cannot find module 'server' or its corresponding type declarations.ts(2307)"

import type { AppRouter } from "server";

[vitorussui]

Haven't tried this with trpc yet, but I've worked on a project where we use Prismic's Slicemachine schemas and types from an external repo as a git submodule, so all external files are synced in a folder in your local repo (like a monorepo).

You could change trpc stuff on both repos if needed (to be honest you don't even need to touch the server repo directly).
All you gotta do is point the front-end repo to either HEAD or the server repo's latest commit on main.

On the front-end repo git will only change the commit ref so it knows which version of the back-end repo you're working with.
Guess it's worth a try...

[dohaicuong]

@bradennapier Sorry I for the late rely, I've actually go down the same solution as @ShunyaWatanabe
Emit declaration type only and publish that to a private npm registry then install that types package for which ever frontend apps using it.

Yeah the problem is setup that is not a nice experience at the moment.
Especially with project using prisma, I also need to run prisma generate, copy that prisma types and fix the import prisma types for it to work

[dohaicuong]

from what I know it seems https://github.com/sachinraja/trpc-playground#types might doing something that similar to our needs here.
using zod-to-ts to get the typescript types for the trpc playground.

I haven't actually digged it down to know what he's actually doing there :p

[gtolarc]

Even within a team or company, there are times when you want to hide the server implementation for security reasons. Therefore, the current trpc structure, which must operate within a single monorepo, seems to be a major obstacle to mass adoption. @KATT

The method of building d.ts with tsc seems difficult to operate properly in a complex structure due to problems with typescript type inference and pnpm library hoisting recognition.

@bradennapier @dohaicuong I think we can start by referring to rspc and zod-to-ts you guys mentioned. I've never done anything like this before, but it would be a great help if someone could implement it.

[KATT]

I don't think tRPC is the right tool for the job if you work in an organization that is so siloed and shrouded with mystery between teams that you can't let the teams read each others' code. You're better off with GraphQL or OpenAPI if that is a requirement (FWIW, In my 15+ year career, I've never worked in such an environment even if I worked for banks, insurance companies, etc).

The whole superpower of tRPC is that it improves collaboration and breaks silos between the backend and frontend.

Some random points:

• tRPC is designed for monorepos & there are several examples of monorepo structure at trpc.io/awesome
• If you don't use a monorepo but want to use tRPC, you have a few options:
  • Migrate your code to a monorepo using Turborepo, Nx, or package managers' built-in solutions (and thank me later)
  • Use a private npm repository to publish the types of your server
  • In your "client" repo(s): use a script to somehow clone and emit the TypeScript types of the backend
  • (We'd love to see some articles covering how to use tRPC in non-monorepos and feature them on Twitter and on our site)
• tRPC is not designed for public APIs, but it works really well with tools like trpc-openapi.
• We don't want to depend on a compiler step outside of TypeScript itself as that would hinder adoption even more by introducing more "magic" that the user would have to trust
• TypeScript deletes all traces of import type at runtime, so you don't need to worry about leaking server stuff to the browser itself:

  import type only imports declarations to be used for type annotations and declarations. It always gets fully erased, so there’s no remnant of it at runtime.

  — Source

• I don't know what "mass adoption" means, but I think we're doing pretty well at the moment:
  

[gtolarc]

I understand that the direction of the maintainer is the most important, and the current popularity proves that the direction is right. However, it would be nice to consider that there are people who thought that it was an RPC technology and tried to use it thinking that each service would be flexibly connected based on stubs. However, since the use of zod is not compulsory, it may be difficult to actually implement it, and it is not a feature that many people really want, which is a pity personally.

[dohaicuong]

Actually my use case is still trpc for frontend.
I have multiple frontend applications and doesn't have the nice monorepo setup to use trpc in the way it introduced. :)

[Elvincth]

My solution for types sharing using yarn link between two repositories, simple and fast

If you're working on two different repositories and need to share types between them, you can use yarn link. Here's how:

1. Create an index.ts file in the root of your trpc project and export the AppRouter type (Point to your own _app.ts path):
   e.g.

   export type { AppRouter } from "~/server/trpc/routers/_app";

2. Add the following two lines to your package.json:

   "main": "index.ts",
   "types": "index.ts"

3. Run yarn link in your trpc project:

   

4. In your other project, run e.g.yarn link "my-trpc-project" to link the package:

6. Finally, just import the type and use it:

   import { AppRouter } from 'my-trpc-project';

That's it! You can now share types between two repositories.

[rubengmurray]

But then the builds will fail... brain dump here from me but I am very keen to explore how to get this working across repos

[shepherdjerred]

You can publish your packages to NPM, pack & install them with npm pack/npm i, or use an npm workspace.

You definitely should not ignore types during CI. CI is there to catch your mistakes.

[rubengmurray]

tl;dr: If anyone has any good articles on managing npm package development across cloud environments I'm all ears. For my use case this 'problem' is not limited to tRPC.

---

Setting aside local development given we have npm link, I'm keen to explore a proposal for segregated repositories in the cloud. One where multiple people could be working on the same repository and thus export different API types packages during development. That is a common use case for my team and without a solution to that it's difficult for us to get using tRPC fluidly.

Something like:

• repository X on branch 1 pushes a set of proposed changes to its tRPC APIs
• The types for repository x are required by repository y on branch 1 - which is actively running in the cloud - for the same feature.
• Therefore, the requirement is that, even during development, the types for branch 1 get published to a registry.
• However, someone else is working on the same repository (repository x) on branch 2 on a separate feature, and they push their changes and those types need to be used by repository z (which is also running in the cloud).
• For this to work in a well isolated manner there needs to be some way of differentiating the repository x development types package on branch 1 from the branch 2 package until we merge into main.
• In short: you don't want to install types that are not accurate to the code that is running on your particular cloud environment.

I can think of a few of ways to do this, but a couple of them feel a bit clunky, particularly when it comes to package.json handling

1. Publish name-spaced packages including the branch names (e.g. repository-x-types-branch-1@1.0.1) and use these during development.
2. Tag packages with npm publish --tag.
3. Create a private registry per environment and publish to and install packages from there (at least for private repos)

I feel like 3 could potentially be the most scalable and least clunky from a developer perspective. I have used 1 in the past and it gets tiresome reverting package.json back to the original package names. I fear 2 would have the same drawbacks.

Thoughts welcome.

(After writing this, I've stuck a tl;dr at the top and I'll probably go search again elsewhere to for solutions as this definitely isn't a tRPC problem.)

[shepherdjerred]

Big tech companies have tools to solve the problem you're describing. Outside of that, your best bet would be to use a monorepo since git will quickly solve that problem for you.

More information about the general problem and how AWS solved it is here: https://gist.github.com/terabyte/15a2d3d407285b8b5a0a7964dd6283b0

[rubengmurray]

Cool. Thanks for the link.

[chibat]

In this use case, "ts-rest" may be a better match.
"ts-rest" can expose the contract separately from the server implementation.
https://ts-rest.com/

[mkosir]

If somebody will find it useful I created example boilerplate on using tRPC with separate BE/FE repositories.

[rehanvdm]

I wrote a blog about the best course of action if you want to have separate backend and frontend repos and still use tRPC. It is AWS Lambda based but can be applied to any tRPC implementation. There are also code repos. https://blog.cloudglance.dev/trpc-separate-backend-frontend-with-openapi-aws-lambda-cdk/index.html

By design, tRPC is meant to be used in a mono repo project. This should always be your default for tRPC
projects if you can, if not then the best course of action is to generate an API SDK from the backend and consume
it in the frontend.

In this blog we:

• Use a backend, frontend and API SDK repos running on AWS backed by the AWS CDK
• Showcases tRPC + trpc-openapi
• Generate an OpenAPI spec file from the tRPC code and then from that a JS API SDK, TS types and sourcemaps
• Show how the API SDK is pushed to the API repo and also published to GitHub Packages (similar to NPM)
• Use build system that consists of NPM scripts, wireit and a custom TS file used to execute commands
• Run tests setup for both unit and e2e and use breakpoints
• Show that local development is possible:
  • By starting an Express server from the tRPC lambda code for the backend
  • By starting the Vite dev server for the frontend

GitHub repos used in this blog:

• pets-backend-v2
• pets-api-v2
• pets-frontend-v2

[RikusWiehahn]

Expanding from an answer above,

I have a separate Front End and Backend and solved this as follows:

My directory structure

• Project folder
  • client (NextJS App)
  • server (Node.js Express Backend)

My AppRouter is in server/src/router.ts

// in server/src/router.ts

export const appRouter = router({
  /// procedures in here...
});

export type AppRouter = typeof appRouter;

Then in server/package.json I have the following scripts added:

{
    "trpc-types": "npx tsc --declaration --strict  --pretty src/router.ts --outDir temp --emitDeclarationOnly",
    "move": "mv temp/router.d.ts ../client/src/config && rm -rf temp",
    "types": "npm run trpc-types || true && npm run move"
}

• The first one exports the types to a folder called temp
• The second on takes the specific type declaration file for the appRouter and moves it to a Front End folder I have chosen (client/src/config), and then deletes the temp file
• The third one combines these two scripts (runs both regardless of errors in first script)

From the terminal in the server folder I can run the command npm run types to export the types

Then the tRPC setup on the Front End imports the types from the file I created:

// in client/src/config/trpc.ts

import type { AppRouter } from "./router"; // <-- The type declaration file created

export const api = createTRPCProxyClient<AppRouter>({
  links: [
    httpBatchLink({
      url: `${serverURL}/trpc`,
    }),
  ],
});

Whenever I make changes to the Back End I run npm run types and it updates the types for the Front End.

Hope this helps someone!

[shrikantshet]

Tried on a large project, it results in The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.