Optimizing "Internal Packages" bundling to prevent dependency nesting

[JoelBrenstrum]

Bundle Optimization Issue: Internal Packages & tsdown

We are currently using the Internal Packages strategy, and while the setup is working well, we've identified a bundling issue.

The Issue

When performing a single bundle using tsdown (where noExternal is set for internal packages), the bundler includes all the third-party dependencies of our internal packages directly into the output file.

• The Conflict: Firebase/GCP correctly installs these dependencies into node_modules during deployment because they exist in the isolated package.json. However, because they are already baked into the bundle, the application never actually loads them from node_modules.
• The Goal: We want our internal packages to be bundled as source code, but their third-party dependencies to remain external so they are loaded at runtime from the environment's node_modules.

Attempted Solutions

I experimented with making all third-party dependencies of our internal packages external. This successfully kept the bundle lean, but introduced a new failure:
The app fails at runtime when attempting to import them because they weren't installed in the final container/function environment. Because the dependencies didn't exist in the root package.json.

Requested Outcome

I'm looking for a way to treat internal packages as source (bundle them) while ensuring their third-party dependencies are treated as external and correctly tracked in the deployment package.json.

[JoelBrenstrum]

I was able to come up with a simple solution that works for us.

1. I tweaked the tsdown config to get a suitable bundle with Internal Packages and without any third-party deps.
2. I ran isolate-package
3. I modified the pnpm-workspace.yaml in the isolated package output and added shamefullyHoist: true, which hoists all the third-party dependencies of our internal packages to the root.
4. Voilà

Let me know if you think this is a suitable fix.
I would love to see a possible option in isolate package when using internal packages for this.

[0x80]

Hi @JoelBrenstrum I have only used the internal packes stategy myself once for testing. All my monorepos bundle each package separately.

I don't really know what a good solution would be for this, and I don't see myself investing much time in this, but if you come up with a solution I'm of course open to PRs.

Recently I added a long-requested feature by someone who also using the internal packages approach, so maybe that is also useful to you if you didn't already find it... See #156