Closed RobbieTheWagner closed 8 years ago
Any ideas as to how I can remedy this @roman01la?
@rwwagner90 Hi. Can you please setup reproducible example? I need a way to see how it works and find the cause.
No problem @roman01la ! I put up a branch of our library attempting to use this compiler. Please pull down https://github.com/jibeinc/juice/tree/webpack-closure .
After getting the code, you should be able to just:
npm i
npm run build
Then go into the examples folder and open any of the html files to run an example. You should see the error in the console.
Please let me know if those instructions are straight forward enough or not.
Thanks! I just checked. Unfortunately the problem is not in ClosureCompiler, but in the code of libraries transpiled with Babel.
When compiling ES2015 module with default export, Babel wraps that export into an object with a special prop __esModule
. Later in code when this module is imported, a helper function from Babel is used to check is the module is ES2015 module. And if it is, it will just return that object, but if not — it will wrap it again.
The problem is that in those checks __esModule
prop gets munged by ClosureCompiler, so it makes those checks always wrap exports into an object again.
I don't know if there's a solution to this. On one hand Babel should access that prop using brackets notation ["__esModule"]
so GCC will not munge this. But it is also possible to write a small Babel plugin which should rewrite this prop from dot notation to brackets notation before passing the code into GCC compilation step.
Hope this explains well.
@roman01la if that is the only issue, is it possible to pass an option to the compiler to not mangle that string?
I just came across this explanation while looking for this exact problem, although with another project. Is this a babel bug or is there a transpiler flag / setting (as @rwwagner90's asked)?
I tried using this plugin, but I got errors like:
Uncaught TypeError: Super expression must either be null or a function, not object
Any ideas?