Issues with watch task

[void lava]

Hi there,
I am kinda new to the whole nodejs backend thing. I was more into Spring Boot the last couple of years. Because of that I was pretty happy to found nestjs......nice piece of software! 🙂

Background
Currently my team evaluates if it nestjs is something we could use. I started a very simple project to find out if I can serve a good developer experience with it. Basically my project is a monorepo with a very simple package module1 and the nestjs app uses module1 in the package.json.
Problem
When I now run the dev scripts (using turbo repo) and change internals in module1 (for example change a string in the private function's list) module1 recompiles but nest-app doesn't pick up the changes. Also it doesn't do the restart and still serves the old value when hitting the endpoint.
If I change the string AND touch the exports of the file (for example export a new const) it catches up the changes, restarts and serves the new value.

To drill down the problem I tried the exact think with a monorepo using typescript only script (tsc -b -w) and with is it worked.
I put everthing on github: https://github.com/Dragoopai/ts-monorepo

I would really appreciate your help! In the best case I hope I just misconfigured something.

Thanks in advance

[void lava]

Maybe worth to mention:

when I replace nest start --watch by tsc -b -w and run npm run dev at the root again I see that the nest-app recompiles if I make those changes to module1

[void lava]

Is there something I can do to get feedback for my issue?

[modest shard]

I'll try to find some time to take a look. turborepo always seems to act weird with Nest stuff

[void lava]

I am pretty sure I tried it running the tasks separately without turbo.

[modest shard]

Yes, but the way things get set up with turbo, the way the packages are set to work with each other, it can lead to interesting things

[void lava]

Okay I am glad if you have some insight!

I setup the monorepo by myself without "npx create-turbo". Maybe I did something wrong in that regards.

[void lava]

What also pops into my mind is that I noticed that even with the typescript-only approach (main) it did not work until I used "-b" on the tsc command. I tried out to find out if nest-cli uses this parameter when running "nest start --watch"...but I failed. 😉

[modest shard]

Ah, okay, re-reading through everything here, yeah, you'd need the -b which nest build doesn't support at the moment.

Are you super sold on turborepo as your monorepo management tool? I only ask because I use Nx which has an incredible dev experience when it comes to these cross library restarts and integrates really well with NestJS

[void lava]

Thanks for your answer! No I just making my first steps with those topic so I could also with Nx a try. What I do not understand is what makes Nx better than turbo in that regards? Even with Nx I would like to have a project structure like the one I created in my example repo. So I would still need the "-b" option, wouldn't I?

[modest shard]

so, the way Nx sets everything up is to not use @nestjs/cli or tsc to compile the applications, but swc or webpack (default) unless projects are specifically set to be buildable. What this means is that these libraries/packages are bundled into the application, and properly referenced using tsconfig path aliases instead of installed as packages via the package.json. It's essentially all pre-configured to "just work"™️, which I find incredibly attractive with a monorepo.

I also fine a lot of flexibility in the end, with being able to build custom executors and tooling as necessary. I've got an executor that builds my docker packages and one to run biome as a format and lint tool, for example

And the mental model that Nx promotes (code in the libraries, not in the application) leads to the same idea that Nest subscribes to of making modules for your code

[void lava]

Thanks again for sharing your thoughts! What I understood so far is in the context of my problem Nx setups a more appropriate structure because it uses path aliases instead of references (like I do). So basically it works with the need of having the "-b" option. If this works well with next it is maybe worth to check if my problem can be solved with path aliases and turbo repo first. From my perspective it doesn't matter if I note down the references or path aliases in the tsconfig but if it works with path alias I would stick to them. I will definitely try this out. Thanks for the hint. And about turbo, Nx and monorepos in general: The only things which matters for me are that it has a good user experience during development on the whole monorepo (watch, recompile, restart), it should work with nest and I need the packages which are used internally also publish to a npm registery so other teams can use them. So those packages have their own identity, basically a package.json. The nest docs are also referring to monorepos and libraries but (for me) it looks like those libraries in the docs or generated by the cli are not usable in other projects because they do not have separate package.json therefore they can't be released separately (Maybe I am wrong about that). Because of this I tried my custom approach. I started with turbo repo because it looked for me like it has a smaller feature set than Nx but still fulfilling my use case. Long story short: I heard you, Nx is worth a look, but for now I first have to build up my knowledge about tsc, nest and how it works together before jumping on that. But I am very glad you shared your knowledge!

Do you have any info if/when we can get the "-b" option in the nest cli?

[void lava]

Hi there,
I tried to implement the "path-mapping" solution but again failed. I also cleaned up a bit the example repository by explaining a bit more about the different approaches. Hope that helps.
Here is the branch with the "path-mapping" approach: https://github.com/Dragoopai/nestjs-ts-watch-issue/tree/nestjs-with-path-mapping

I would really appreciate if you can give me some feedback about it. Thank you very much in advance.

[modest shard]

Appreciate your patience while I was taking care of other things as well.

So, the path mapping you have here kind of is in the right direction, but still not completely there, because what's happening is you are pointing at packages/module1 which then checks the main of the package.json to see that it should be pointing at dist/index.js.

Now, when dist/index.js changes, that does not trigger a re-compile in typescript, because the typescript files haven't changed, which is why you need to manually restart.

One way around this is to point :module1 to ../../packages/module1/src however thismesses up the compiled output from dist/main to dist/app/nest-app/src/main because of how Typescript tries to keep the same file structure when you compile.

Typescript does not do any code bundling, which is what causes the "messed up" structure of the dist when pointing at the src of the library.

The way Nx gets around this is to use webpack to bundle the application to a single output file, so that it's always in the same place. <workspaceRoot>/<apps|libs>/<name>/main.js and because it can point at the ts files instead of the compiled js files, it can auto-restart on compile

Technically, you can set webpack: true in the compilation options, but due to how Nest has some internal optional imports, and the monorepo structure of turbo interferes with the resolution of the webpack.config.js that Nest has initially (still don't udnerstand why) you'll need to create your own webpack.config.js

[void lava]

Hi, thanks again for taking the time to help me out. Essentially I got from your post (and please correct me if I am wrong) that the "nest start --watch" (internally without the "--build" on the tsc") only watches the types of my library and if they change it recompiles and restarts. Your suggestion, as far as I got it, is to use webpack instead because it would also watch the files. But wouldn't it be more straight forward to allow to have the "--build" on the "nest start --watch". I mean in general I am happy with the typescript compiler not to bundle everything. Using webpack looks for me adding more unnecessary complexity.

But beside that...does nobody else have such requirements. I mean watching on a library in mono repo seams not sooo special, right? Maybe I thinking fundamentally wrong in that regards??
Have a nice evening!

[modest shard]

I mean watching on a library in mono repo seams not spoon special, right
No, it's not some special thing, but most people, when they start working in monorepos, end up using webpack for this reason.

If you do have typescript point at the src of the library, like I said before, it'll mess with how the output of the application's compile works.

I think there's a PR for this, but I could be wrong. If not feel free to make one.

Almost every time I need a monorepo, I reach for Nx. Rather than worry about setting it up myself, I'd rather use something that works out of the box here. Monorepos can get tricky, and not needing to worry about it so much has been helpful for me.

[void lava]

Okay! Then I will give Nx a try. I think they have a generator for nestjs applications, right? If you maybe have sample repo which mostly fulfills my requirements I would appreciate it if you can share it. Thanks a lot!

[modest shard]

Yes they have generators. And yes, here's my side project with several libraries, applications, and shared libs between front and back end

[void lava]

Oh thanks for sharing. When I look into "libs/ui/race" for example. How to publish this as a separate package to a registery. It does not have a package.json instead it has a project.json. Or does Nx also handle the publish without having a package.json?

[modest shard]

Ah, that part I don't have in this project. However, ogma does have that capability and nx's documentation explains how you can handle "publishable" libraries

[void lava]

Grrrreat! Thank you very very much! I will look into that as soon as possible.

Btw is there also a chance of getting some help in such more general topics on this discord. I mean your doing it but I feel a bit bad because it goes beyond nestjs.

[modest shard]

This server? Not really. We try to keep it to NestJS