Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for transpiled modules #16

Merged
merged 3 commits into from Dec 24, 2015

Conversation

Projects
None yet
4 participants
@Victorystick
Copy link
Member

commented Dec 1, 2015

Don't merge yet

This PR tracks how best to handle CommonJS modules that have already been transpiled by Babel, TypeScript or something similar. These CommonJS modules define a __esModule property on their exports object, and export their default export as a default property.

We should:

  1. remove the __esModule property
  2. use the default property for the default export instead of the module.exports object

Fixes #10

Oskar Segersvärd
@Rich-Harris

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2015

Would it be appropriate to warn users in this situation? It may be that we're dealing with external packages, in which case the user may have limited control, but it might help people understand that their Babel config is messed up etc

@flying-sheep

This comment has been minimized.

Copy link

commented Dec 23, 2015

messed up? does this mean it’s somehow not working as intended? why?

@Rich-Harris

This comment has been minimized.

Copy link
Contributor

commented Dec 23, 2015

@flying-sheep Messed up as in Babel is being used to convert ES6 modules to CommonJS modules, which means Rollup has to convert them back to ES6 modules so that it can bundle them (quite possibly in order to generate a CommonJS bundle). Keeping everything as ES6 until you need to run it is the name of the game.

@flying-sheep

This comment has been minimized.

Copy link

commented Dec 23, 2015

ok, but how? jsnext:main should point to a “distributable” package, not a ES2015 package… should we really introduce another field and copy of the lib for an ES2015 version?

i’ll comment in rollup/rollup#337 about it.

for this issue and plugin, i think we should simply detect the most common ways stuff is distributed and be practical instead of idealistic. this is a practical plugin, written for a world of commonjs modules. it should “get” as many of them as possible.

@Rich-Harris

This comment has been minimized.

Copy link
Contributor

commented Dec 23, 2015

Should have been more specific – I meant keeping everything as ES6 modules is the goal, since that's the only thing that's getting translated back and forth otherwise.

@flying-sheep

This comment has been minimized.

Copy link

commented Dec 23, 2015

makes sense. this is a frequent language confusion in the discussions here.

but still: both should be supported as we can’t hope to convince everyone to use jsnext:main (which means adding build configs and doubling package size) and therefore should be practical.

  1. let’s help redux with fixing their use of jsnext:main
  2. let’s finish and pull this PR

then we can actually work productively with rollup as node_modules bundler

@Victorystick

This comment has been minimized.

Copy link
Member Author

commented Dec 23, 2015

Looks good to me. 👍

Rich-Harris added a commit that referenced this pull request Dec 24, 2015

Merge pull request #16 from rollup/handle-transpiled-modules
Add support for transpiled modules

@Rich-Harris Rich-Harris merged commit 25e4cf0 into master Dec 24, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@Rich-Harris Rich-Harris deleted the handle-transpiled-modules branch Dec 24, 2015

@Rich-Harris

This comment has been minimized.

Copy link
Contributor

commented Dec 24, 2015

Have released this as 2.0.0 (since it's technically a breaking change) – it doesn't include warnings about already-transpiled modules, but we could revisit that in future if we choose

@bfred-it

This comment has been minimized.

Copy link
Member

commented Mar 19, 2016

Sorry, I think this change is indeed breaking support of rollup modules in browserify/babel. If you export default but not __esModule, browserify/babel won't pick that up. I had left a comment here too: rollup/rollup#496 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.