juliankrispel / jsio-codemods

A bunch of codemods to turn code reliant on the jsio compiler into es6 modules
MIT License
0 stars 0 forks source link

Default Exports #9

Open juliankrispel opened 8 years ago

juliankrispel commented 8 years ago

So in light of the issues discovered in this pr I'm now changing the exports mod to be much simpler. cc @yofreke

Here's what I'm doing:

So basically this:

exports = Hello;
exports.foo = 'dwq';

becomes this:

var exports = Hello;
exports.foo = 'dwq';
export default exports;
yofreke commented 8 years ago

This es6 seems unintuitive at first glance. What are your thoughts on something like:

export default Hello;
exports.default.foo = 'dwq';

I don't like overwriting exports, and while yours is not, it is also not very clear what is happening until the end, since exports is already defined in the module scope.

juliankrispel commented 8 years ago

I think mounting on exports.default is wrong because it's implementation specific to the compiler.

How about just renaming exports to defaultExport

Julian Krispel-Samsel rainforestqa.com goodafternoon.co

On Aug 23, 2016, at 9:12 PM, Joe Brown notifications@github.com wrote:

This es6 seems unintuitive at first glance. What are your thoughts on something like:

export default Hello; exports.default.foo = 'dwq'; I don't like overwriting exports, and while yours is not, it is also not very clear what is happening until the end, since exports is already defined in the module scope.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

yofreke commented 8 years ago

ty es6

I suppose that is true, since we haven't settled on a compiler yet. What about the following:

const defaultExport = Hello;
export default defaultExport;
defaultExport.foo = 'dwq';

That way any references to exports in the file will still work as intended.

juliankrispel commented 8 years ago

Ok cool. It seems to me like it's pretty conventional to put the export statement at the bottom of a file but if you have a good reason for having that at the top that seems fine. I don't really care too mucg either way tbh.

Whaddayasay

Julian Krispel-Samsel rainforestqa.com goodafternoon.co

On Aug 23, 2016, at 11:56 PM, Joe Brown notifications@github.com wrote:

ty es6

I suppose that is true, since we haven't settled on a compiler yet. What about the following:

const defaultExport = Hello; export default defaultExport; defaultExport.foo = 'dwq'; That way any references to exports in the file will still work as intended.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

juliankrispel commented 8 years ago

That seems to work for me though. The thing about not being compiler specific is not just about us choosing a compiler but also user-land. Ideally this should work with whatever other peeps are using. Whether that's webpack or browseriify or whatever else

Julian Krispel-Samsel rainforestqa.com goodafternoon.co

On Aug 23, 2016, at 11:56 PM, Joe Brown notifications@github.com wrote:

ty es6

I suppose that is true, since we haven't settled on a compiler yet. What about the following:

const defaultExport = Hello; export default defaultExport; defaultExport.foo = 'dwq'; That way any references to exports in the file will still work as intended.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

juliankrispel commented 8 years ago

@yofreke also bear in mind you can define exports as a normal variable and babel will adjust to prevent any collisions at compile time - here's and example

var exports = null

export default {}

will compile to

"use strict";

exports.__esModule = true;
var _exports = null;

exports.default = {};