Performing a migration from Next.js to NestJS using a PNPM monorepo and Turborepo.

[bronze galleon]

Hello,

We are migrating away from NextJS due to certain deployment limitations, specifically the lack of canary deployment support caused by server-side actions. As part of this migration, we are rewriting one API call at a time into a NestJS application. So far, we've found NestJS to be a great framework—pleasant to work with and intuitive.

However, we've encountered a challenge: sharing our Prisma library between the NestJS and NextJS applications. To address this, we've transitioned to using pnpm workspaces combined with turborepo. While NextJS works out of the box with Just-in-Time (JIT) compilation, NestJS presents a different issue.

The Issue

When transpiling NestJS TypeScript into JavaScript, we need to use the commonjs modules configuration. However, to enable JIT compilation, the module resolution must be set to bundler. Ideally, we’d like to configure pnpm such that both applications can use newer module resolutions (nodenext, preserve, or es2015+) seamlessly.

Question

How can we configure our pnpm monorepo to share the Prisma package between both NextJS and NestJS applications effectively? If you have a solution, could you kindly share an example?

[bronze galleon]

Performing a migration from Next.js to NestJS using a PNPM monorepo and Turborepo.

[crude olive]

Can you explain a bit more what you mean with JIT complilation and how that is different than just building Nest as usual? Because, it sounds like a modules conflict in the end, i.e. you need to build your prisma library to commonjs for it to work in Nest too.

[lunar patio]

Ok I managed to do the same in another project

I have NestJS backend, a nextjs frontend as apps

Then I have a database package that's basically prisma

Am on prisma 6.5 so I can output to a directory and then I export the index.js from the generated prisma folder, I can then import them from both NestJS app and nextjs app

I did this mostly to share types but you can also share the prisma client

Here's the repo

https://github.com/tracepanic/learn-sphere

Maybe this may help am not sure

[bronze galleon]

Hey,

Thanks for the replies.

So yeah, the basic issue is, next can import prisma using JIT
The idea is that, you can say that the importer has to package the library for you.

Using nest, you need to use commonjs, but commonjs is not supported by next for the import. (the issue lies mainly in the fact that you have 3 client in prisma)

@lunar patio, I think the trick lies in your tsconfig, you seem to be using nodenext + setting the path.
I think that is our issue as then you are using JIT 🙂

[lunar patio]

Yeah that's the hack I did that on the tsconfig

[crude olive]

Off topic, but a simple tip in Discord to set a link in your reply text. Just highlight the text and do a control V having copied the link. It will set the link for you. 🙂

[bronze galleon]

I tried, it did not work 😄

(I am on discord web, that may be the reason why 🙂 )

[lunar patio]

Ok on the module resolution for NestJS am using node16

[crude olive]

Testing it now.

It works in web too.

[bronze galleon]

(ok that's because https for discord to get that it's a link 🙂 )

[crude olive]

Ok. Back on topic. 🙂

[lunar patio]

Also did this hack coz import couldn't work

"paths": {
"@workspace/db": [
"../packages/database/generated/client"
]
}

That's on NestJS package json

[river basin]

I have a turbo repo project with nestjs/nextjs + database shared package and everything is working. Took me some fiddiling around with tsconfigs to get it working but its been perfect so far. It's in a private repo so I can't share the repo but I can share my config files.

[crude olive]

I get JIT compilation now.

Is it Nest you wish to use JIT with?

[bronze galleon]

We need to be able to use it for both Next and Nest.
So our issue.
We have a database, using prisma. most of the code is in Next, we need to move it to Nest, but we can't do it as a big bang. We need to do it bit by bit 🙂

For this, we setup a mono repo, with a shared package (prisma) that shoul be used by both nest and next

[crude olive]

Ok. So, later you might change to a more flexible compilation mode in Turbo? I ask because

1. you shouldn't be using only TypeScript for compilation purposes with Nest (even though the base build process in the CLI does). You'd be tying your hands from being able to do much better and faster things, like with SWC.

2. further on the build performance subject, once your application gets larger, caching build steps becomes crucial for making changes faster and more importantly, less costly. You might not see that happening now, but it will be a problem in the future, once your team grows (assuming your team is small now of course).

Just sayin. 🙂

[river basin]

I've shared my tsconfigs for the root monorepo, api (nestsjs) app, web (nextjs) app and the database (prisma) package. I don't remember exactly what I did to make them all work together but it was related to the tsconfig.

[bronze galleon]

We are already using turbo for that part yes.
We moved to next/prisma/turbo. It's working.
So we know our setup works for next/prisma.
When we add our nest application, then it stops working.

We may try to move to SWC, but that was not yet the plan 🙂

[crude olive]

Is the plan to completely move away from server actions in the end? I still don't get having the mix.

To me server actions is a kludgy addition to solve a problem that most people serious about creating backend apps (like with Nest) don't have. If you have the mix, your frontend devs then have the cognitive load of two different data fetching/ mutating processes and no valid added value for doing it the two different ways. On the contrary, it adds a level of decision making they shouldn't need to worry about at all.

At any rate, I'm just rambling. 🙂

I hope you now have your problem solved.

And thanks to you two @river basin and @lunar patio for your input. Much appreciated!

[river basin]

Anytime I can help I will. Gotta give back to NestJS for being awesome

[lunar patio]

NestJS is awesome, I tried golang but it feels like express, I just want something full like NestJS

[crude olive]

I got the same feeling with Go too. It is still a great language and theoretically, a Nest-like framework could be built on top of it too, but well, we don't have that yet. 🙂

Go was also mainly built for small service applications. Imagine Nest calling a Go service to get work done. Oh yeah. That is where Go would thrive.

[lunar patio]

Yeah I get it, maybe one day we'll get such a framework

[crude olive]

I asked AI about this and it spit out two possible candidates close to Nest's "ideology". FX from Uber and Wire from Google. 🤔

[craggy bear]

A bit late, but I wrote an explanation for how to set up JIT transpilation with Turborepo, PNPM, Nest and TypeORM in [this thread](#1347278129017651250 message)

There may be some additional challenges with Prisma due to limited ESM support.

[bronze galleon]

To add to it.
Using Prisma and next no issues.
Moving to nest and using commonjs for nest. Ok.

Using the same monorepo package in both 💀

Why don't we don't it in one go ?
We work for a company, and we need to deliver. Telling to our boss, we will stop delivering for the next week's as we are migrating is a no no

Hope that answers all the questions

The thread you share seems quite interesting.

We will investigate that route. We also believe that moving to swc will help. We were still trying to figure out why our tsconfig for nest does not support nodenext or preserve+bundler