Closed mparpaillon closed 6 months ago
Using noExternal goes against the purpose of isolate-package. The main point of the isolate extraction is that you can treat your internal dependencies like regular NPM installed dependencies, and have their dependencies installed according to their manifest.
I think bundling dependency code together with your business logic is generally undesirable. I wrote a bit about it in this article.
Oh since you were using it in your example I took it as an valid option. Thanks for the response
I forgot I was using it there. It's been a while since I worked on this and I don't use this strategy in my own projects.
I think the noExternal there is required to bundle the code from common, but I'm not 100% sure.
The common package still needs to be part of the isolate bundle and the package manifest dependencies list, in order for the package manager to install all of its dependencies, because the common package itself is not bundled with noExternal.
I got it working without the noExternal. Your repo and article helped me a lot this week. Thanks
I realized there was a problem with the common package strategy. If you're still using that pattern you might want to read this https://github.com/0x80/mono-ts/commit/d0186fea48d41667203b5bd46addcde84033c0b3
Hey! Kudos for this repo. It helped me a ton.
I'm using the noExternal option to include everything in my final bundle but there's a problem.
Scenario A: I keep @repo/common in my package.json dependencies
Everything works but it isolate the @repo/common for nothing since everything is already in the final bundle thanks to noExternal
Scenario B: I remove the @repo/common from package.json dependencies
That way the isolate only has the final bundle and its package.json BUT it doesn't work but the @repo/common dependencies are not merged with the bundle package.json
So, for now I'll keep the @repo/common dependency in my package.json but I shouldn't have to right?