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?
Why don't you want the whole module? Because it's bloat? Surely it's far less bloat than one submodule per function?
Every line of code that isn't used is bytes you're sending to every user unnecessarily
> Surely it's far less bloat than one submodule per function?
How is that bloat? It's the same LoC whether it's 1000 modules or 1 after it's been compiled/minified
I'm not arguing that there shouldn't be a math module but that you shouldn't split it up into such (imho) crazy small parts.
Closure Compiler can remove any unused functions.
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.
It's easier to keep an eye on a small number of trusted parties than 200 random strangers.
You thought this SNAFU was bad...
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?
No one knows.
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.