Problem with unused library functions

[hcvazquez]

My name is Hernan; with a group of colleagues we are conducting a research about unused code present in dependencies of JavaScript projects. We call this functions, UFF (Unused foreign functions). We found that in most projects there exist a great amount of UFF that are being included in the final bundle.

In the case of transform-pouch (v 1.1.3) our tools detected approximately 78 unused function in dependencies. Removing those functions, the size of transform-pouch bundled could be reduced at least 26% (All tests passed). I replaced the bundled in several projects that use transform-pouch as pouch-pid, crypto-pouch, pouch-box. I’m attaching the reduced version of your project.
pouchdb.transform-pouch(optimized).txt

I’ll be very grateful if you can answer me the following questions:
-Did you were aware of the existence of these unused functions in your projects?
-Do you think that this is a problem?
-Do you think that can be useful a tool for deal with this kind of problem?

Thanks in advance.

Cheers,

[calvinmetcalf]

I don't know if you are familiar with 'code coverage' tools which are used in conjunction with tests to make sure all paths through the code are adequately tested, there is also a concept that certain optimizers do called 'dead code elimination' which attempts to remove code that can probably never be run.

Modern tools tend to do this at the statement level not the function level (I.e. Remove branchs of an if statements).

Code coverage tools tend towards false positives because just because code is not run doesn't mean it will never run (I.e. The code will only run on certain platforms) while dead code elimination tends towards the opposite leaving in code it can't rule out from being run.

To circle back to your original questions

• it looks like you were testing againt a bundled version of this lib, the bundle can include boilerplate or unused functions for other platforms. Though it's hard to tell based on sending us the cleaned up version telling us what you removed would be more helpful then telling us what you saved.
• whether it's a problem will actually depend on what sort of tool you actually have, is it based on static analysis or on runtime data, if it's based on runtime data then the functions probably arn't unused but you just didn't run through all possible scenarios, if it's static then they likely are unnecessary but we run our library through a minifier (uglify) which has dead code elimination so will probably remove the code for us.
• as for whether this is useful it depends on what exactly it does, if it's dynamic it's usefulness would depend on it being better then Istanbul which works at the expression level and gives super user friendly output showing you exactly what parts of the code are run, if it's dynamic you'd have to compete with uglyfy, the Babel minifier, and to an extent, rollupjs.

Hope that answers your questions.

[nolanlawson]

Yes to add to what Calvin said, this is interesting research, but in general what's more valuable is code coverage tied to unit tests and to the existing build system. You've sent a text file of a reduced JS file and that solves the problem for the current version, but it doesn't change the build process when we need to change something...

I agree JS bloat is a problem and thank you for the info, but I don't believe this kind of tool is extremely useful unless it can be automated and unless it can be applied to users using all kinds of bundlers (Browserify/Webpack/Rollup/etc.). Thanks though!