Nestjs module as a GitHub submodule

[ashen nymph]

I know this may sound crazy but has anyone seen that a nestjs module is developed in it's own repository and then added as a GitHub submodule to the main nestjs application?

The background of this is I am building a chat module with nestjs that I want to reuse in different apps. So I am asking if this submodule approach makes any sense?

I have also considered putting the chat into its own microservice but I read that for starting out and for startups it's better to start with a monolith.

[crystal kelp]

I've seen and used git submodules to build apps in the past. And every time it's been a bad experience keeping stuff synchronized. I mean, it totally can be done, but I've found it much simpler to instead publish private npm libraries that can be consumed by other apps. In your case, I would create a configurable module and publish it to a private github npm registry.

[dreamy goblet]

I wish I could it more than once. At my workplace, we currently have a submodule and I dread dealing with it every time. It's a massive pain and a monorepo or a private package (depending on the need) would be a much better approach

[ashen nymph]

does nestjs have docs about this? I only found https://docs.nestjs.com/cli/libraries . Which shows how to create a library but only for use in a monorepo. like it's not published to npm.

I found this tutorial, is it good? It doesnt't use the nest cli. But if I would use nest cli would I do nest g library my-library or just nest g module my-module-to-publish?

https://blog.entrostat.com/packaging-nestjs-modules-for-npm-installs/

Why is there not a official documentation about this cause it's quite useful?

[dreamy goblet]

Why is there not a official documentation about this
Because I keep getting busy and haven't gotten around to writing anything on it. 😆

Generally, I nest new a new project, move all @nestjs/ deps to devDeps and add @nestjs/core and @nestjs/common to peerDeps. Add a files to thepackage.json and set a main property as well. Remove the src/main.ts and add src/index.ts (what I set main to) which exports the package's public API, then develop as normal, use either nest build or just tsc to compile the library, do integration testing in the tests directory, and viola, that's essentially it

[ashen nymph]

ok thanks I will try that too. what I did was nest new then nest g library and then I did nest build my-library to build the library in the dist folder. then I am publishing the dist folder to github's npm.

this is a part of my package.json:

{
  "name": "@github_username/my-library",
  "version": "0.0.3",
  "files": ["dist", "README.md"],
  "description": "",
  "author": "",
  "private": false,
  "license": "UNLICENSED",
  "main": "dist/libs/my-library/index.js",
  "publishConfig": {
    "registry": "https://npm.pkg.github.com"
  },

however even tough I published the npm package and it is called the same as my repo it is not diplayed under the published packages in my github repo:

but I published the package:

and you see its called the same and I read if repo and package are named the same it should diplsay it under published packages in the repo:

[dreamy goblet]

I've never used GitHub's npm registery, so not sure what's going on there. From what I can tell, everything else looks right though

[thorny silo]

I got no issues on using github registry; under an organization
the package is called @np-qp/private-npm-package

[ashen nymph]

I am using github registry under my personal account, not Organization. Maybe that's the problem?

[thorny silo]

maybe? I'm not sure on how that works tbh

[ashen nymph]

but I think it's a bug

[thorny silo]

but can you install that package?

[ashen nymph]

didn't try that, I will try

[ashen nymph]

yes I could install it and I also ran some methods from the package and it worked.

[ashen nymph]

and for testing the library. Do you import the library from the project directly and test it. Or do you publish it locally with npm link and then import that published package and test that?

[dreamy goblet]

I write integration tests in the tests directory, usually

[ashen nymph]

I mean to test the lib you can either do:

import { MyLibraryService } from './my-library.service';

or

import { MyLibraryService } from '@organization/my-library'

for the latter you need to do npm link and npm link @organization/my-library.

The advantages of the latter are that you are testing the same package that is published. So if someone messes up something in the publishing process like something gets messed up in package.json then the tests will fail. but if I use the former approach tests will still pass.

[dreamy goblet]

I don't usually link the library locally to anything. I'll just end up using the integration tests to confirm it works, then publish and install in my project

[ashen nymph]

so with integration tests you mean you import the service from you local projects folder and test it?

[dreamy goblet]

No. I mean in the tests directory of the npm package's workspace, I have an applicationthat can make use of the package, and do the full tests that it needs to for it. @nestjs/throttler is a godo example ofthis

[ashen nymph]

so if someoen would add bugs to the package.json and somehow publish the wrong package like by chaging the "main": to a wrong path your test would fail?

[dreamy goblet]

Hopefully you review the PR and notice that that would be an issue

[ashen nymph]

but test would fail or pass?

[dreamy goblet]

Test would pass because it's not tied to the package.json

[ashen nymph]

yeah thats what I meant

[dreamy goblet]

Again, there should be code reviews to catch that, at least hopefully

[ashen nymph]

yeah sure. so you think it's OP to extra npm link it only to also test for that?

[dreamy goblet]

The thing is, just npm link has issues with Nest packages due to npm link not properly respecting peerDeps. You can npm pack and make a .tar so that you install the tar and then respect the peerDeps, but regular npm link doesn't work so you've got to take the extra steps.

[ashen nymph]

ok I tried npm link and it worked

[dreamy goblet]

So while you're at it with those extra steps, why not write a CI job that checks if the package.json's main or files fields were modified and if so add a comment with super bold letters saying "THESE FIELDS WERE CHANGED. DID YOU MEAN TO DO THAT?"

[ashen nymph]

but I dont have any peerDeps maybe thats why it worked

[dreamy goblet]

Do you have @nestjs/ packages installed?

[ashen nymph]

yes

  "dependencies": {
    "@nestjs/common": "^10.0.0",
    "@nestjs/core": "^10.0.0",
    "@nestjs/platform-express": "^10.0.0",
    "reflect-metadata": "^0.1.13",
    "rxjs": "^7.8.1"
  },

[dreamy goblet]

1. those shouldn't be dependencies they should be devDeps and peerDeps for the library because when installed in the application where @nestjs/common and others are installed it'll cause dependency issues that Nest won;t properly resolve due to JS realms
2. what is the project you're linking this to? Does it also have Nest packages installed?

[ashen nymph]

1. ok I just did nest new and it put it under dependecies. I will look into that.

2. it's the same project as the library. My tests are in the same repository and use he same package.json.

[dreamy goblet]

If it's all in the same project/workspace then the linkning may not end up being an issue. If you link across repos however, I guarantee you'll run into problems

[ashen nymph]

ok I will try that and see if I get problems thanks for the tip

[dreamy goblet]

I still would not recommend using link even if it is to the same repo where everything is. If you're super concerned about the package.json, just make a CI job that warns about it. That's my opinion though, if this works for you then great