pmowrer / rollup-plugin-peer-deps-external

Automatically externalize `peerDependencies` in a rollup bundle.
MIT License
109 stars 16 forks source link

I wonder why **deprecated** `includeDependencies` #50

Open helloint opened 3 years ago

helloint commented 3 years ago

rollup should externalize all the deps as well by default, since upper level project or package will install all the deps of current package, the best practice is to let that level to properly handle the optimize and bundle.

I think includeDependencies should be true by default if no consideration of backward compatible.

pmowrer commented 2 years ago

I wonder why deprecated includeDependencies

As its name implies, this package is specifically about externalizing peer dependencies

rollup should externalize all the deps as well by default, since upper level project or package will install all the deps of current package, the best practice is to let that level to properly handle the optimize and bundle.

I would argue all deps you don't want to bundle into a library should be peer dependencies.

rmfruit commented 2 years ago

PeerDependencies signal 'there can be only one' though. React is the canonical example since you can never have 2 versions at the same time. A package author sets the required version of React as a peerDependency and if another package needs something different npm stops. The person using the packages has to figure out what to do since npm can't.

But many packages (most?) don't have that restriction. If a package author sets package A@^1.0.0 as a dependency and some other package also uses that version npm will install it once for both. Smaller bundles, faster installs, etc, etc.

That can't be done with peer dependencies as far as I know.

pmowrer commented 2 years ago

PeerDependencies signal 'there can be only one' though.

I agree with all of that, except...

If a package author sets package A@^1.0.0 as a dependency and some other package also uses that version npm will install it once for both. Smaller bundles, faster installs, etc, etc.

... having to include multiple versions of the same library would lead to a larger bundle and longer installs, not the other way around.

That can't be done with peer dependencies as far as I know.

That seems fine? Sorry, I don't follow what the argument is.