Why isnt there a Bundler for sfdx projects?

[AllanOricil]

Why are sf project dependencies installed in Salesforce as another package, in its global scope (org), instead of being scoped by the parent package boundaries?

Have anyone thought about creating a bundler that would scope dependencies under a common parent package, then package it as a single dist? If yes, what is the limitation that can't make this approach viable in the platform?

With this approach:

1. Org can have 2 installed packages referencing different major versions of the same dependency.

2. Patches can be applied to a common dependency (same major.minor.patch) of 2 different dependant packages at different moments. This also means one won't need to test all "dependant" packages at the same time after patching a common dependency. It is now possible to do one at a time.

3. It won't no longer be necessary to install dependencies before installing the package, since everything the package needs is already in it. But that does not mean it can't still use global dependencies if it needs.

4. A package could be easily uninstalled alongside its own dependencies, not global ones.

There would no longer exist need for resolving the dependencies at runtime, since this job was already done at build time, like seen in artifacts created by other programming languages. Moreover, installed packages would be decoupled from each other.

When I was working in sf projects I always felt confused why dependencies were installed in the global scope of an org prior to installing the parent package. I know that this happens just so that the parent package can resolve its dependencies at deploy (or validation) time. But It always felt weird because it works differently than the way we build artifacts in other programming languages. At the time I didn't bother asking someone why it was done like that, and I still don't know the answer, but I would like to understand it. Maybe I actually didnt understand how packagrs work in the platform. Why not treat package and its dependencies as a single artifact?

sf package:build would be responsible for creating the artifact that can be installed in an org. It bundles all metadata under the parent scope, and outputs a .sf archive that can be installed in any Org. Bundling does not mean, for example, that apex classes will be all composed into a single file, but that dependencies are scoped by the package boundary. Think about what esbuild, webpack, rollup do. They allow devs to bundle dependencies while keeping them into the node_modules folder.

This command would work like the one found when building vscode extensions. Before publishing an extension in the vscode marketplace, a .vsix archive is created. This file can then be installed in any vscode, and it already has all its dependencies packaged in its scope. When running, it won't look for dependencies at the global scope.