It feels like some sort of a tree shaking solution in most of our modern development stacks is long overdue.

If only we could get rid of dynamically called code and instead could evaluate which code paths the code actually can call, then we'd be able to throw out about 90% of the contents of libraries, since most of the time noone actually uses all of that functionality.

Doing that with separate scripts is another approach, but it feels like the problem should be solved at its root.

It sounds like what's already available in C#.

https://docs.microsoft.com/en-us/dotnet/core/deploying/trimm...

This sounds like it could be equivalent to the halting problem

With a conservative analysis it's possible to make an underestimation on the names one can remove. This shouldn't be done on object files but at a level where program flow information is still preserved. A flow-independent analysis using a superset lattice over the callable names should do the trick for a first-order implementation that will look good enough compared to shipping 37mb for google authentication. Further you could make it flow-sensitive for a more accurate analysis with the caveat that the runtime will be significantly longer.

Control flow graphs are well-studied, critical parts of most compilers. The halting problem involves complexity of semantics in loops and jumps, but it’s possible to understand what loops may run just fine, without being able to decide exactly when a loop may exit.

In many cases Clang and GCC compiler can easily understand loops, and even reduce them to constant time.

But Composer is the cause of all those file dependencies. Things like Composer and NPM encourage devs to re-use scores of 3rd-party libraries rather than writing new code; those libraries also rely on NPM/Composer; so they also have scores of dependencies. And it's impractical to audit them all.

I don't understand why people are so willing to depend on these crazy dependency trees, where most of the code was written by people you don't even know the names of.

Before dependency managers, you downloaded a zip with php files from people you dont even know the names of. (And never update any of the external libraries)

These managers dont replace the chain of trust, if you dont trust a dependecy and the developer behind dont install it.

"And it's impractical to audit them all." I dont use NPM but for composer.json: https://github.com/fabpot/local-php-security-checker

I agree, composer is not perfect, but before it was worse.

"I tried removing unnecessary services from composer.json. Still 14000+ files."

Validate a User Only: composer.json

    {
        "require": {
            "google/apiclient": "^2.10"
        },
        "scripts": {
            "pre-autoload-dump": "Google\\Task\\Composer::cleanup"
        },
        "extra": {
            "google/apiclient-services": [
            ]
        }
    }

=> vendor folder size: 6MB, 1012 Files

Cool. I did not remove enough services it seems.