Problem with unused library functions about transform-pouch

[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!