Question: can we get list of tree-shaken modules (which were marked as external?)

[chrisui]

This would be useful for building up minimal package.json dependencies of lambda functions. We track modules marked as external to create and install the minimal production dependencies for a given entry point however we currently (without a second parse) know if any of these external modules were dead-code anyway (which tree-shaking encapsulates the logic of).

Is it possible to expose this if it's not available already?

[hyrious]

You can use plugins to track every import expression and mark some of them as external and collect them. In fact, I had the same requirement months ago to help me find out unused dependencies in package.json, and I quickly written one:
https://github.com/hyrious/esbuild-dev/blob/b551d77e2ce6d9a908a9ca4056aa5d980031c573/src/utils.ts#L34

[chrisui]

You can use plugins to track every import expression and mark some of them as external and collect them. In fact, I had the same requirement months ago to help me find out unused dependencies in package.json, and I quickly written one: https://github.com/hyrious/esbuild-dev/blob/b551d77e2ce6d9a908a9ca4056aa5d980031c573/src/utils.ts#L34

Cheers. We do actually have a plugin that collects these however resolve appears to happen before tree-shaking meaning that you will collect modules that may never actually be used (as indicated by the fact the tree-shaking algorithm removes them from the bundle later).

[tinovyatkin]

We are reparsing bundle with Typescript (as we had that available in CDK, but you may use any other, including esbuild itself) like that https://gist.github.com/tinovyatkin/727ddbf7e7e10831a1eca9e4ff2fc32e. As as reporting in #1933 the imports field from metadata may be very useful for that, but, unfortunately, it's not getting populated.

[chrisui]

Thank you @evanw