How to attach external source-code library to monorepo

Description

I have a monorepo that is in turn dependent on a set of libraries, of my own writing, which I have separate because I use them in other projects and some day may open source them if they prove robust and useful enough. So basically, they are not in my monorepo for this reason. BUT I would love to have my monorepo setup such that they are effectively “in it” and I gain the same benefits that I do with my other libraries i.e. changes to them would be instantaneously reflected in my monorepo. To that end I have tried to add a path in my tsconfig.base.json file pointing to the source-code outside of my monorepo code (pretty much exactly what you do to reflect the lib/<project> path inside the monorepo). e.g.

"paths": {
    "@<myscope>/<my_extern_lib>": ["../<my_external_lib_src_dir>/index.ts"]
}

I get a couple of problems right off the bat trying to serve an app dependent on this library.

1. Sass does not seem to recognize this path. I get SassError: Can't find stylesheet to import for a line that reads ~@<myscope>/<my_extern_lib>/scss/styles

2. I get the error ERROR in Unable to write a reference to <MyComponent> in <my_external_lib_src_dir>/<path_to_component> from <my_external_lib_src_dir>/module.ts

So angular also is having an issue compiling this.

Any thoughts on how to properly make this work?

Motivation

It would be super awesome to have this say when you have an issue with a 3rd party library and you create a fork to try and fix the problem. If you could have an easy way to attach the source code from this forked repo into your monorepo it would make fixing and submitting pull requests a breeze.

Suggested Implementation

So ultimately an awesome thing would be …

nx generate external_lib <name> <path>

Alternate Implementations

[agentlewis]

Hey @crowmagnumb. Just wanted to share that we have a similar requirement and I have been looking at various solutions.

We are a consulting firm and for most clients end up needing to publish several “apps”. Each client also has at least 1 library we create for them.

We then in turn have several libraries we have developed in house that we use across client projects (api adapters and runtime validation libraries). Ideally we want to be able to add-hoc develop these while we are also working with our client solutions.

The ideal would be if NX allowed for a lib to have its own github repo, package.json and build/publish command. Essentially allowing us to pull it in and work with in within the nx solution - but publish out changes as needed. I could see how this could be a git-submodule solution. But I have been down the submodule path before and learned that its very hard to have a team of devs working with it.

As such we are now looking to use meta with yarn workspaces as a foundation for each client. Into this we will add our cross-client packages (and repos) and a new nx solution.

Something like:

• meta-clientName (github repo) - created from github template. inc. yarn/npm workspaces for efficient installs of libs.
  • customLibrary1 (github repo - published to github private package)
  • customLibrary2 (github repo - published to github private package)
  • nx-clientName (github repo) - created from cli (plus changes to support firebase functions)
    • .npmrc file to access published private packages
    • apps
      • clientApp1
      • clientApp2
    • libs
      • clientLib1 (published to github private package)
      • clientLib2 (published to github private package)
  • *clientNameIsolated (github repo) - created from a github template
    • .npmrc file to access private packages inc. clientLib1 & clientLib2

* Sometimes we will want to bring a contractor on to work on a specific thing and not want them to have access to all the code - this could be for security or we don’t want to ask them to learn NX, Typescript or something else. In this case we will make another client repo in meta and bring the dev into that specific work space. Once they were done we would likely migrate the code into nx as an app.

With this we are hoping the DX of developing client solutions with cross client packages will improve.

Anyway I haven’t tested this yet - I need to first finish refactoring from lerna to NX. But this plan is feeling pretty solid for now.

cc @iainkirkpatrick

[agentlewis]

@jebesampaio (and others that pinged me - sorry I never replied)

So in the end we did not use meta - just yarn workspaces and github rep templates.

We also used a seperate yarn workspace for publishing the private npm packages that were used across several projects. These are published to Github as private node packages.

This worked ok, but did not become the “system” we could standardise across the company.

My business partner and far more technically read friend @iainkirkpatrick has just done a new push for our business on creating a mono-repo template using TurboRepo which having just seen his work, looks very promising.

I could see this working in tandem with repo templates and possibly still a seperate project with cross project libraries existing being published from a different repo.

So basically we are not using nx any longer 😦

I think there are features in nx we would like to have, but stanardising via repo templates and shared published packages has ended up being a simpler solution for us.