So have libmath depend on libsin, libcos, libtan and libsinh. People who want the kitchen-sink version can get it. People who want just one specific submodule can depend on that. What's not to like?
Having a full set of math functions isn't kitchen sink, it's the right level of granularity for a module. If I want math functions I really want them to all be written by the same author and kept in lock-step as a unit.
Why don't you want the whole module? Because it's bloat? Surely it's far less bloat than one submodule per function?
It's not bloat in the source code - if you don't care which pieces you depend on you declare a dependency on math, if you do care you list the specific pieces.
It shouldn't be (impactful) bloat or overhead in the build system or dependency management. That stuff should just handle it.
Most of the time you don't care and can just declare the dependency on math and let the closure compiler handle it. But sometimes it might be really important that a project only used cos and not sinh, in which case you want to enforce that.
Maybe you're running on an embedded processor that can do sin/cos/tan with high performance but sinh performance is bad. Maybe part of your project needs to depend on an old version of sinh with a correctness bug so that you can reproduce existing calculations, so you don't want any other parts of the code depending on sinh. Maybe your legal team doesn't want you using sinh because they believe the implementation might infringe some patent.
In the compiled artifact there might not be a difference. But developers tend to ignore the issues outside their scope. So yes, for a developer it might not make much difference. For people who need to make sure that you can compile and deploy, it's much more complexity.
If basic, bog-standard functionality was built into the standard library, then it's not bloat that you have to deal with. 500 kb or a meg or two for a decent, full-featured standard javascript library isn't going to even make a dent in the install sizes of web browsers, even on awful mobile devices.
There's a cognitive load to every additional thing you need to know to use a module. At a certain point, added flexibility becomes more trouble than it's worth.
What's not to like? The fact that every one of those dependencies is an attack vector when one of those package's maintainers gets compromised / project hijacked / bought off by some black hat operator.
It's easier to keep an eye on a small number of trusted parties than 200 random strangers.
That has nothing to do with how granular packages are. The npm is broken as it allows such things. Look at this spectacular example of providing high security for users: https://www.npmjs.com/package/kik
Someone has to do this manually?! If the package is not popular, no one cares? What happens if I send them an email and provide the same package with the same API (not trademarked and MIT licensed) but break it a bit on every update?
when those packages are not under your control, it has everything to do with how granular they are and by extension how many you depend on and thus have to trust/verify.
when was the last time you rechecked the entire source of a package you depend on after updating it?
That depends; in the case of mathematics libraries they have to be bundled together because of functional dependencies. It's either that or ignoring DRY principles -- which if you do that, you're ignoring the entire point of what breaking things into submodules is intended to do.
Separate interface and implementation. cos and sin might well use common underlying code (by depending on the same module), but they should expose orthogonal interfaces.
