Thank you for the extensive feedback! As I see, there is no perfect solution so far... I had to deal with git submodules in one of the previous projects and remember the experience was not that nice. Also tried to publish them to NPM in another project, it also comes with annoying workflow in a fast-changing codebase. So I have to really think about the way for the next project...
I consider the mono-repo approach to provide the least friction when it comes to fast changing codebases. Throw in a CI solution, automated tests+typescript and you end up with a very easy to maintain workflow.
This is especially true for full-stack TS projects, where sharing types between the client+server-side code can create an extremely "refactor-able" code base.
I also should of mentioned you could use dedicated mono-repo tools like lerna even for smaller full-stack projects to help share code. Generally though, if you package code (using npm or other systems), you have to deal with versioning pains.
With monorepo approach beware of what you importing and where. You occasionally can import a function or class that can be shared, but importing a big module e.g. TypeOrm. As a result, you can have megabytes of unneeded code in your frontend. That always going on with Next.js monorepo projects in my case :-)
I've seen this, but importing typeorm to the client-side usually creates other unforeseen errors related to the fact typeorm isn't suppose to work there. (Same goes for any "back-end focused" library)
Optimally, un-used code in the project is dropped via tree shaking. This is only possible if the library in question works well with it.
There's also situations where libraries don't work well with bundlers (lots of native google-cloud packages don't work with webpack) and in these cases workarounds are a must.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.