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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.