As modules are recursively resolved and generated, the plugin should track an esImported value for every module that is found.
The esImported value will be false in either of the following conditions:
the module was imported using require or AMD syntax
the module was imported like import foo from "./bar"
However, the esImported value will be a truthy array if the module was only ever imported like import { subFeature } from "./bar" or import { otherFeature } from "./bar". In this case, the esImported value will be an array with string elements "subFeature" and "otherFeature".
After all modules have been resolved and generated, the plugin will take another pass over each module, looking for export nodes at the root level of the AST. For each module with a truthy esImported value, any export nodes that do not match an element in the esImported array will be removed.
Lastly, sub-dependencies that are no longer needed must be detected and removed from all dependency lists. This is because the function that consumed a particular dependency may have been purged. Some investigation may be necessary to ensure that we don't just implement a minifier. If it proves to be too difficult, we should have a two-stage process - one step before a minifier is applied and one step after, at which point any removed requires would have to be detected.
Notes:
Base features should work without a minification step.
Can tree shaking be extended to a subset of comparable CommonJS-style imports? One approach can be to remove entries from the export object and let a minifier clean up declared but unused functions/imports. This could be detected using either import { foo } from "./bar" or var foo = require("./bar").foo. This will not work with all packages, but may help with common use-cases (like Lodash).
How should removal of exports impact the module's hash? Should there be a second hash step for modules that are streamlined? (yes, there should)
divmain
commented
8 years ago
As modules are recursively resolved and generated, the plugin should track an
esImportedvalue for every module that is found.The
esImportedvalue will befalsein either of the following conditions:requireor AMD syntaximport foo from "./bar"However, the
esImportedvalue will be a truthy array if the module was only ever imported likeimport { subFeature } from "./bar"orimport { otherFeature } from "./bar". In this case, theesImportedvalue will be an array with string elements"subFeature"and"otherFeature".After all modules have been resolved and generated, the plugin will take another pass over each module, looking for
exportnodes at the root level of the AST. For each module with a truthyesImportedvalue, anyexportnodes that do not match an element in theesImportedarray will be removed.Lastly, sub-dependencies that are no longer needed must be detected and removed from all dependency lists. This is because the function that consumed a particular dependency may have been purged. Some investigation may be necessary to ensure that we don't just implement a minifier. If it proves to be too difficult, we should have a two-stage process - one step before a minifier is applied and one step after, at which point any removed
requires would have to be detected.Notes:
import { foo } from "./bar"orvar foo = require("./bar").foo. This will not work with all packages, but may help with common use-cases (like Lodash).