Fork me on GitHub
#cljs-dev
<
2017-10-08
>
thheller08:10:14

@dominicm not sure what the CLI flags are, but for ES6 you need to set :language-in and for commonjs you need

thheller08:10:17

(.setProcessCommonJSModules true)
            (.setTransformAMDToCJSModules true)

thheller08:10:29

(on the CompilerOptions instance)

thheller08:10:05

there are probably flags for those

dominicm08:10:32

@thheller I was doing something like that. But it wasn't outputting namespaces, just a bundle of everything together.

thheller08:10:00

yeah picking them out one by one is probably not supported by the CLI

dominicm08:10:51

It seems like the closure library used to provide a python script to do this, closure builder, but it's deprecated and doesn't seem to support cjs namespaces

dominicm08:10:01

This is frustrating, because CJS code simply doesn't compile to a good namespace, and is just broke.

dominicm08:10:26

Is it perhaps more appropriate for me to officially report this to the cljs team, who can provide the equivalent settings to Google based on what's being done under the hood? I guess I'm moving towards figuring out how cljs uses closure, which might be a few days spelunking to figure out for a beginner to the code.

thheller08:10:16

why do you need the sources? I think for closure the intention is to do as part of the optimization process

thheller08:10:38

they added a new optimization level “BUNDLE” recently maybe that does what you need?

dominicm08:10:45

They're generating sources which are not providing namespaces when separate.

dominicm08:10:53

I tried that, no cigar.

thheller08:10:23

why do you need that though?

dominicm08:10:48

@thheller I'm using the JavaScript module support to use some CJS files in a CLJS project.

thheller08:10:05

yes, and you want to reproduce a bug? but why do you need separate namespace to reproduce it?

dominicm08:10:23

The bug is to do with local vars vs global ones. They do var in the generated code, which is fine when sharing (or so compilation suggests!), but not when separate.

thheller08:10:28

hmm I was just looking through some commits and was confused by one thing

thheller08:10:52

goog.provide('module$foo'); var module$foo = ...; is that the var you are talking about?

thheller08:10:24

usually goog.provide is not followed by a var

dominicm09:10:45

Yes! That is wrong

dominicm09:10:50

Only happens for CJS though.

dominicm09:10:57

ES6 is fine

dominicm09:10:12

For me it was always followed by var module$foo = {}

dominicm09:10:24

which then locally scoped the module, meaning it didn't get exported.

thheller10:10:25

feels wrong but I don’t know if thats always been like that

dominicm10:10:19

Looks like it has for > 1 year.

thheller10:10:25

not sure, I haven’t used the closure stuff much recently since it was way too unreliable in many cases

dominicm10:10:45

(I based that on older tests)

juhoteperi11:10:33

I wonder how this can be a problem because I have used Closure successfully with CJS modules

thheller11:10:40

@dominicm are you running in the browser? did a quick test and the extra var definitely is not an issue there

dominicm11:10:58

I was compiling for nodejs.

dominicm11:10:29

A quick way to repro is to run through the js module sayHello, but port the es6 module to cjs

dominicm11:10:39

Oh, and bump the cljs version to 908

dominicm12:10:00

the browser working makes sense I guess, the var is global there. Nodejs provides scope to vars.