[victorNicollet]

Tree-shaking is able to remove code that will never be called. And it's not necessarily good at it: we can detect some situations where a function is never called, and remove that function, but it's mostly the obvious situations such as "this function is never referenced".

It cannot detect a case such as: if the string argument to this function contains a substring shaped like XYZ, then replace that substring with a value from the environment variables (the Log4j vulnerability), or from the file system (the XML Entity Extension vulnerability). From the point of view of tree-shaking, this is legitimate code that could be called. This is the kind of vulnerable bloat that comes with importing large libraries (large in the sense of "has many complex features", rather than of megabytes).

[account-5]

Thanks for the explanations, much appreciated.

I suppose the options are then:

1. Write everything yourself, time consuming and hard, less likely to lead to these types of vulnerabilities.

2. Import others code, easy and takes no time, can lead to vulnerabilities.

3. Use others code, but only what you actually need. Maybe less time consuming than 1 but more than 2, adds a different sort of complexity, done correctly less likely to lead to these vulnerabilities.

Not sure if there's any other options here?

[victorNicollet]

I would say 4. grab individual code files (as opposed to entire libraries) and manually edit them, removing unnecessary features and adding new ones where needed.