Monorepo

[guyulmaz]

Hello, is it possible to have a "project monorepo" for enterprise environment, As explained in https://www.youtube.com/watch?v=q4XmAy6_ucw So one monorepo for nestjs server apps, web apps, nativescript apps, shared libs... All will share same node modules directory, same versions...

[thomrick]

Hey @guyulmaz !

Nice question ! The answer is in my opinion : yes if the team needs it and can handle it ! Be careful about the CI / CD hooks for example ! ;-)

[BrunnerLivio]

Yes it is possible atleast in the backend. Frontend development is not possible (yet?) with NestJS (Angular is the way to go). I've created with the project lxdhub a monorepo with NestJS. For example my package @lxdhub/db contains a Nest module, which is used by the packages @lxdhub/api and @lxdhub/dbsync.

It can get quite hard at some points and it uses a lot of computer power to develop with it. VSCode gets really slow because of the complex module resolution sometimes.

I've used Yarn workspaces, which correctly resolves the dependencies for each package and Lerna to orchestrate them

My inspiration for the build architecture was the repository Quramy/lerna-yarn-workspaces-example

I've invested quite some time on this topic. Feel free to ask any questions :)

[xmlking]

Other example based on #nx workspace https://github.com/xmlking/ngx-starter-kit

[BrunnerLivio]

Started monorepo starter for NestJS. Feel free to check it out and leave some feedback https://github.com/BrunnerLivio/nestjs-monorepo-starter/

[marcus-sa]

You should use https://nrwl.io/nx if in this case it's an Angular & Nest app Example: https://github.com/ForetagInc/fullstack-boilerplate

[duro]

@BrunnerLivio I'm running into problems specifically with nest in a monorepo structure. I've been deving in this structure for some time now, but only just started running into issues when trying to add nest to the repo.

We break our workspace up into two workspaces, one called packages where shared libraries go, and another workspace called services which usually end up depending on a few things from packages.

The problem I am running into is that when something from packages depends on @nest libs, and the service also depends on @nest libs, I end up with a them installed twice. I've even ensured that they are using the same versions, but I still end up with a version in the root node_modules, and another in the services node_modules.

This ends up causing issues with including providers from a package into a service, as that package's DI resolver can't find things like the Request, etc.

Any insight on this?

[kamilmysliwiec]

@duro define them as peerDependencies, not dependencies

[thomrick]

If it can help :

Left package.json is user-service application and the right is the database-lib one.

[duro]

@kamilmysliwiec, @ThomRick: thanks, I was able to get it working. I had been doing the approach you guys mentioned, but for some reason it wasn't working. Perhaps something went wrong with my yarn.lock. After a few cleans and re-installs it was resolved.

That said, this approach seems to essentially lock all packages and services to a single version of Nest, especially in development. Since the dev deps get installed working locally, if a new one is created that installs a new version, that will cause a break working locally.

Have you guys ran into this, any suggestions on how to keep this sane in the long run?

EDIT: I'm seeing this happen a lot now using dev/peer dependencies locally. Even when the dependency version numbers are exact.

Example, here is a package package.json:

{
  "name": "@freebird/nest-typegoose",
  "version": "1.0.0",
  "main": "dist/index.js",
  "private": true,
  "files": [
    "dist"
  ],
  "scripts": {},
  "dependencies": {},
  "devDependencies": {
    "@nestjs/common": "^6.1.1",
    "@nestjs/core": "^6.1.1",
    "reflect-metadata": "^0.1.12",
    "rxjs": "^6.0.0"
  },
  "peerDependencies": {
    "@nestjs/common": "^6.1.1",
    "@nestjs/core": "^6.1.1",
    "reflect-metadata": "^0.1.12",
    "rxjs": "^6.0.0"
  }
}

And here is a service that depends on that package:

{
  "name": "@freebird/nest-example",
  "version": "1.0.0",
  "description": "Freebird nest-example service",
  "main": "dist/handler.js",
  "private": true,
  "scripts": {},
  "dependencies": {
    "@freebird/nest-typegoose": "1.0.0",
    "@nestjs/common": "^6.1.1",
    "@nestjs/core": "^6.1.1",
    "@nestjs/platform-express": "^6.1.1",
    "aws-serverless-express": "^3.3.6",
    "express": "^4.16.4",
    "reflect-metadata": "^0.1.12",
    "rxjs": "^6.0.0"
  },
  "author": "Freebird",
  "devDependencies": {
    "@types/aws-serverless-express": "^3.3.1"
  }
}

I am consistently getting an extra copy of @nestjs/common inside the package, while the service uses the one installed in the root node_modules.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

[kamilmysliwiec]

Just incase others find this thread.

We have announced official Monorepo support (full article) to create additional Applications or Libraries all within a single monorepo workspace.