External packages guide

I’m submitting a…

[ ] Regression 
[ ] Bug report
[ ] Feature request
[x] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

No documentation available.

Expected behavior

Have a documentation available that describes how to import custom nestjs components in a project from another project. It would be great to have an overview what works, what doesn’t work and how to split a large project in smaller subprojects.

Imagine that I have a project that is called “@mycompany/common”. This project is a nestjs project and contains components like guards, pipes, exceptions filters, interceptors etc. that I would like to use in many other projects as a “company boilerplate” base (I could also copy the relevant files to the individual projects, but that would result in duplicated code and hard to manage bases).

Now I have another project called “@mycompany/myAwesomeProject”. This project has the line

"@mycompany/common": "file:../common",

under “dependencies”, so that the files in the common package are available. It would be great to have a documented overview, what needs to be done: Do the nestjs packages need to be listed as “peerDependencies”, “devDependencies” or just “dependencies”? How can components such as guards, exception filters etc. be imported so that they work as excepted (For instance I made the observation that thrown http exceptions inside a common exception filters cannot be distinguished in type and are thrown as plain “Errors”, but thats just to give an example). Is there anything that doesn’t work? How can different nestjs versions be managed in individual projects? How can multiple local installations of nestjs be avoided in the boilerplated code?

I do understand that some of what I described has only little to do with nestjs itself (especially package.json setup), but nonetheless it would be great to have it documented. Also it would be great to know what works in imported projects and what is expected not to work.

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Ability to share code across multiple projects using a common project.

Environment

Nest version: 5.3.6

 
For Tooling issues:
- Node version: v10.10.0  
- Platform:  Mac 

Others:

[dngconsulting]

same here @kamilmysliwiec , is there any article/pointer providing sample code that shows how to create external module that would be placed in its own repo and consumed thru a basic “@mycompany/common”: “file:…/common” ? Thanx

[cloakedch]

I understand your point. My idea was to have a short guide that describes each necessary step, even when it’s not specific to nest. I’d even have imagined something like an additional cli command that would boilerplate only necessary code and file structure for an (internal) library.

However, should that be clear to nestjs developers then disregard my suggestion 😃

About the peer dependencies: I have setup a tiny test repository here: https://github.com/cloakedch/nestjs-library-example

In app, there are only two routes, where one throws a NotFoundException (which should be caught by the exception filter in the library). The nest packages are defined as peer dependencies. Also pipes and interceptors seem to work, but not filters. Is there anything special about filters?