Fork me on GitHub
#cljs-dev
<
2017-10-02
>
thheller09:10:43

I’m wondering if we should add a new :default option in ns for :require of JS deps to mirror default imports/exports from ES6

thheller09:10:56

import defaultExport, { export [ , [...] ] } from "module-name";

thheller09:10:41

there is currently no way to access defaultExport, it is only available since babel decided to add a .default property when rewriting

thheller09:10:47

it is not part of the spec though

thheller09:10:57

not actually sure what closure does though

thheller09:10:33

(:require ["something/js" :as foo :default bar]) so (bar ...) vs (foo/default ...)

thheller09:10:09

ok checked, closure does use .default as well

thheller09:10:07

might be convenient to be able to use default exports other than always writing lib/default

juhoteperi10:10:19

Hmm, should work with Closure already

thheller10:10:40

lib/default works yes, the questions is whether it makes sense to add :default to requires as a quick alias method (just like import supports)

thheller10:10:05

take this example import RaisedButton from 'material-ui/RaisedButton'; from http://www.material-ui.com/#/get-started/usage

thheller10:10:43

(:require ["material-ui/RaisedButton" :as RaisedButton]) you have to use RaisedButton/default to use it

thheller10:10:58

vs. (:require ["material-ui/RaisedButton" :default RaisedButton])

thheller10:10:59

or (:require ["material-ui/RaisedButton" :refer (default) :rename {default RaisedButton}]) which is horrible 😛

thheller10:10:48

if ES6 becomes more widespread CLJS code will have a whole bunch of x/default references in code … which is ugly

juhoteperi10:10:13

I think when rewriting ES6 modules, Closure exports the default as "root" object also

juhoteperi10:10:45

Or at least it will probably in future, because that is required for using ES6 from CJS

juhoteperi10:10:14

Or maybe not, Chad's solution in the last comment looks like something else

thheller10:10:00

seems unrelated

thheller10:10:42

ES6 has special syntax to refer to a default export, which is why I’m proposing :default in :require to mirror that

thheller10:10:51

otherwise the user always has to use lib/default

thheller10:10:57

that is unrelated to closure

juhoteperi10:10:16

Babel etc. have special support for automatically referring to the default export when requiring ES6 from CJS

thheller10:10:32

no they don’t

thheller10:10:53

well require("something-es6").default

thheller10:10:37

if you require one rewritten ES6 file from another they handle the default yes

thheller10:10:26

unless I’m missing something CJS -> ES6 is left to you

juhoteperi10:10:44

Hmm, okay, my example case for the issue was other way around, ES6 module requiring CJS

thheller10:10:45

they do add a special __esModule property to allow you to detect it

thheller10:10:28

yeah, they have special helpers for that but not the other way arround

thheller10:10:07

but as Chad pointed out

thheller10:10:09

> Adding a default property to module.exports automatically is problematic in some cases:

thheller10:10:16

// Can't add a default property ...
module.exports = undefined;
module.exports = null;
module.exports = true;
module.exports = 4;

thheller10:10:39

so you need to access .default manually

thheller10:10:18

in short ES6 has special syntax for default, CLJS should too

thheller10:10:22

ran into this when testing material-ui and noticed how all the code basically had to use something/default all over the place instead of something

anmonteiro15:10:26

Fwiw I don’t agree with bloating ns even more

anmonteiro15:10:05

It already does too much

anmonteiro15:10:42

Also not sure if there’s even an issue here

anmonteiro15:10:00

Already feels like a step up to be able to require these modules

anmonteiro15:10:26

Accessing foo/default feels like a small price to pay in comparison

thheller15:10:39

The problem is that ES6 code will have quite a lot of those. Just look at any ES6 example out there.

thheller15:10:16

import React from 'react';
import ReactDOM from 'react-dom';
import MuiThemeProvider from 'material-ui/styles/MuiThemeProvider';
import MyAwesomeReactComponent from './MyAwesomeReactComponent';

thheller16:10:01

that alone is 4x React/default, ReactDOM/default, MuiThemeProvider/default, MyAwesomeReactComponent/default

thheller16:10:47

React and ReactDOM are packaged as commonjs so its not an issue .. yet …

thheller16:10:23

personally I prefer a proper way to alias away the default

dnolen16:10:16

I’m with @anmonteiro ns has enough stuff - just not that excited about small affordances like this

dnolen16:10:25

but let’s leave it open and stew on it

dnolen18:10:45

it seems Google Closure Compiler now has a hard dependency on Java 8