gulp-es6-module-transpiler icon indicating copy to clipboard operation
gulp-es6-module-transpiler copied to clipboard

Bundle formatter not working as expected

Open mairatma opened this issue 10 years ago • 0 comments

Using gulp-es6-module-transpiler with the bundle formatter doesn't work as expected anymore after the changes by commit 149c271a009b6ae479b9d76a84c637c32fce3145. The purpose of using the bundle formatter is to have a single output file with all the added modules transpiled together, but that's not possible through this tool anymore.

I followed the discussion on issue #18 to better understand the reasons for the change that caused this problem, and I could see that the proposed solution for using the bundle formatter now is to use some gulp plugin like gulp-concat to concatenate the results afterwards. What you guys probably didn't realize is that this doesn't really cover the use case, since the final concatenated file may have duplicate modules due to the way that bundle formatter works.

Let's say, for example, that I have two es6 files with one module each: foo and bar. And let's say that foo imports bar. When I run gulp-es6-module-transpiler with the bundle formatter I now get two output files, one for each module. The output file for bar will only have the contents from the original bar module. Since foo imports bar though, the output file for foo will have contents both from foo and from bar. If they're concatenated afterwards, the concatenated file will have duplicate code for bar then.

I understand that the previous version of gulp-es6-module-transpiler didn't work well with formatters that had multiple files as output, like CommonJS and AMD. This doesn't mean that now it has to always produce an output file for each input file though. It would work a lot better if it respected the result of es6-module-transpiler's container, producing as output the number of files that the container would have produced with all the given files as input.

From what I see in 149c271a009b6ae479b9d76a84c637c32fce3145, this was almost what was being done before, the real problem wasn't the number of files that were being created for output, but the way these were being named, as the names conflicted and so produced a single file in the end.

So, since I ended up needing this fixed for a current project of mine, I've made some changes on a local branch to go back to having the same number of output files as the container would have created, but also fixing the file names so it works as expected for all formatters (bundle outputs single file, while commonjs and amd output a file per module).

I'll send you guys a pull request with it soon so you can see what I mean and try it out. Hope it can be helpful :)

mairatma avatar Feb 11 '15 18:02 mairatma