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.
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.