thlorenz/es6ify

Traceur source maps seems to be not included

Closed this issue · 10 comments

Given this browserify build,

browserify({ debug: true, standalone: 'Project'})
    .add(es6ify.runtime) // runtime must come first
    .require(require.resolve('./src/index'), { entry: true })
    .transform(es6ify)
    .bundle()
    .on('error', function (err) { console.error(err); })
    .pipe(process.stdout);

The source maps from Traceur seem to be either missing or in an incorrect location as I am seeing the raw JavaScript from Tracur. But..the source maps from browserify are working. Please let me know if I am doing something wrong. Thanks

Attached is a screen screen shot of the issue.
screenshot from 2014-09-26 08 07 19

What versions of browserify and es6ify?

"browserify": "~5.12.0",
"es6ify": "~1.4.0"

Seems like you are correct. Let me try that out.

Actually,
I looked into this and it seems like that example is incorrect. When I move the debug option to the require method, source maps work less well. In the sense, when I leave the debug flag in the constructor , browserify, I get the source maps from browserify. When I move the debug option to the require method I don't even get source maps from browserify.

As @iwillig said, the browserify docs do seem to indicate that the source map debug option is only allowed on the browserify constructor: https://github.com/substack/node-browserify#var-b--browserifyfiles-or-opts

But more importantly, I found that the proper transformed source maps (back to the original ES6 source) are included when the bundle is built using the browserify command line:

browserify ./src/index.js --debug --standalone Project

It only seems to bundle the wrong source maps (to the ES6-ified source) when using the API directly. However, we had to switch to the API because we need the traceur runtime to be included, and there doesn't seem to be a way to include this via the command line (unless we're missing it).

So I do suspect that this is something about the interaction between browserify and es6ify.

This is going to need @thlorenz's expertise. It's strange that the tests are all passing if this is broken, since I know the es6ify tests definitely test source maps.

That's because we still use an older browserify as our dev dep. Therefore the tests use the older API.
I'm open to upgrade to the latest and update the API calls.

Aha, thanks, should have seen that.

So we were using the standalone feature of browserify. It turns out this feature isn't compatible with es6ify (if you need the traceur runtime) in browserify v3.33.1, because adding the runtime to the bundle triggered an error, "standalone option not supported with multiple entry points". That error is fixed in newer versions of browserify (not sure which one, but works in the current v5.12.0); however, es6ify source maps aren't working in that version :)

In our case we were able to downgrade and get around the problem by finding a substitute for standalone. Upgrading es6ify to support newer versions of browserify would at least help anyone using that feature... but I am not sure how common it is. I'll close this issue in the meantime. Thanks again!

Thanks for you guys help.. Closing this as its not relevant anymore.