ease of use, as it works like any other npm package.
costs $ for private packages
github repo's where in our package.json we provide the url to the package. (git submodule)
cost is folded into private github repos
kinda maintainable as versioning isn't easy
requires pushing compiled ts code into source
symlinks/fancier approach
I don't remember how this one would of worked off the top of my head, but it relied on symlinks and was more of the "magical" approach that was much more open ended.
I believe we could of went a number of other routes, but didn't look into them at the time, or don't remember them.
We eventually went with the git submodule route, but found it somewhat annoying to deal with versioning, and updates. As updating required a few manual commands every time to build, and push the code back to github. Handling versioning also became annoying as it was very easy to introduce a breaking change. We probably could of did things better at the time but didn't have time to look into it much more.
After a while we started changing to a monorepo approach, which I recommend for full-stack TS projects, as you can leverage typescript's paths + webpack to build what you want and keep everything versioned the same. (you must have a build step, otherwise the paths approach doesn't work)
I'm currently using angular+nestjs and some nrwl nx-cli packages to be able to build my front-end and back-end using the angular-cli while sharing some common code using typescript paths. I could use angular libs, but I'd consider it overkill for sharing plain types.
If I could go back and do it all again, I'd probably go the npm module route if I could pay, and the parameters of the shared code are well defined. Otherwise I would of went with the mono-repo approach if allowable, as I would be able to remove most of the overhead with sharing code, and versioning.
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.
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.
We looked into a few approaches a while back:
tscode into sourceI believe we could of went a number of other routes, but didn't look into them at the time, or don't remember them.
We eventually went with the git submodule route, but found it somewhat annoying to deal with versioning, and updates. As updating required a few manual commands every time to build, and push the code back to github. Handling versioning also became annoying as it was very easy to introduce a breaking change. We probably could of did things better at the time but didn't have time to look into it much more.
After a while we started changing to a monorepo approach, which I recommend for full-stack TS projects, as you can leverage typescript's
paths+ webpack to build what you want and keep everything versioned the same. (you must have a build step, otherwise the paths approach doesn't work)I'm currently using angular+nestjs and some nrwl nx-cli packages to be able to build my front-end and back-end using the angular-cli while sharing some common code using typescript
paths. I could use angular libs, but I'd consider it overkill for sharing plain types.If I could go back and do it all again, I'd probably go the npm module route if I could pay, and the parameters of the shared code are well defined. Otherwise I would of went with the mono-repo approach if allowable, as I would be able to remove most of the overhead with sharing code, and versioning.
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.