Open conartist6 opened 5 years ago
I still need test coverage for modules when top level symbols are used in exports. Initial testing suggests that this case is failing at the moment.
Also I need to be sure not to remove things which are immediately exported like export const foo = 4
All cases I can think of should be implemented and tested now.
Should I worry that some people will have configured the babel source type of their commonjs modules to be "module"?
It seems like a valid thing to do -- after all cjs files are modules, which is to say that they are not in the global scope.
I think for now I should just look for a top level usage of exports
or module.exports
and prevent any top level optimization attempts in files that have them.
But of course that would mean that if the commonjs plugin ran before this one, this one couldn't remove any top level bindings.
As long as the user hasn't set up two completely separate babel passes it should be fine I'd think though since this plugin does most of its work upon entering the Program node.
OK I've disabled the optimization on cjs modules.
@boopathi Could I get a review on this?
@hzoo could you review this and #953 ? @boopathi "may be slow to respond" but I've been waiting for 5 months. You at least have been active in the repository.
@boopathi ping. Will continue to ping you every three months until you make any comment at all on this or declare that the repo is not open to outside contributions, which seems to me to be the case.
Hey I still want this feature. I guess I own dead code elimination now too! My my, I do pick up an eccentric collection of maintainerless projects.
Fixes #954
Also works correctly with the "unambiguous" module type setting.