The same as it deals with common code paths: What can't be guaranteed to never be called, it left in. E.g. you can remove functions in a module that are never imported anywhere else and never called, rather easily. You can also remove branches that are unreachable, e.g. inside an if (false). But for things like
function f(s) {
if (s === '') throw new Error()
...
}
there probably are very few tools that will statically be able to tell that f is never called with an empty string and thus the validation logic is not needed. It's JS after all and tools that mangle it all fall on a spectrum between doing very little, but very safely and trying to do too much and breaking code.
Comments
How does treeshaking deal with error paths (or other uncommonly used code paths) that aren't often used, but are important not to throw out?
The same as it deals with common code paths: What can't be guaranteed to never be called, it left in. E.g. you can remove functions in a module that are never imported anywhere else and never called, rather easily. You can also remove branches that are unreachable, e.g. inside an if (false). But for things like
there probably are very few tools that will statically be able to tell that f is never called with an empty string and thus the validation logic is not needed. It's JS after all and tools that mangle it all fall on a spectrum between doing very little, but very safely and trying to do too much and breaking code.