Clojurians
#cljs-dev
<
2017-03-14
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

martinklepsch15:03:12

Anyone ran into this kind of thing while experimenting with the new modules stuff?

anmonteiro15:03:38

@martinklepsch did it not work?

anmonteiro15:03:15

Cyclic deps should work in module_deps.js. Not sure how Closure handles it

dnolen15:03:17

@favila huge thanks for the investigation

dnolen15:03:39

and patch!

martinklepsch15:03:37

sorry should have provided more info. I can correctly calculate the inputs (mostly took cues from your om/react experiment) but once I load the page I get an error that something that’s in position.js isn’t defined:

Uncaught ReferenceError: module$$Users$martin$projects$weekly_log$node_modules$mobiledoc_kit$dist$commonjs$mobiledoc_kit$utils$cursor$position is not defined at range.js:33

anmonteiro15:03:50

@martinklepsch so here's a guess. That may not have anything to do with cyclic dependencies, but with a Closure bug related to hoisting https://github.com/google/closure-compiler/issues/2265

anmonteiro15:03:29

I could be wrong though

anmonteiro15:03:58

The best way to rule it out is compiling Closure Compiler from master

anmonteiro15:03:57

@martinklepsch also you may wanna try CLJS master too, as you can just specify :npm-deps {:mobile-doc "version"} and require it directly from a CLJS namespace

anmonteiro15:03:31

That way you avoid all those hacks I did when this wasn't available

martinklepsch15:03:24

I’m on CLJS master but will try Closure master too

martinklepsch15:03:39

re :npm-deps how does that know which file is “the file to load” for a given name? E.g. What I’m doing manually in the following snippet

juhoteperi15:03:34

Default is index.js and package.json can declare different name as entry file

martinklepsch15:03:23

Ah right, forgot about that :slightly_smiling_face: I know nothing about NPM lol

martinklepsch15:03:58

Btw, I tend to agree with the people suggesting that this shouldn’t be a ClojureScript compiler concern. Simple primitives > easy configuration.

martinklepsch15:03:13

One will come out of the other eventually.

anmonteiro15:03:28

@martinklepsch package.json declares a main entry

anmonteiro15:03:40

we use that to figure out what is the entrypoint for a module

martinklepsch16:03:29

Is there anything special needed for locally building closure-compiler? I ran their mvn thing, added [com.google.javascript/closure-compiler “1.0-SNAPSHOT”] and have a jar in my m2 but get "Failed to read artifact descriptor for com.google.javascript:closure-compiler:jar:1.0-SNAPSHOT”

martinklepsch16:03:47

Just saw — it’s looking for a closure-compiler-parent jar ?!

anmonteiro16:03:47

@martinklepsch oh you’re just better off copying the thing in your target folder to your local project directory

anmonteiro16:03:10

and adding that to the classpath

martinklepsch16:03:44

so I build the jar and add it to the classpath manually? did you look into why we can’t just consume via maven?

anmonteiro16:03:16

I never tried

anmonteiro16:03:50

I knew it would be hard cuz I had tried it like a year ago and couldn’t get it to work

anmonteiro16:03:00

this time I was just looking at the fastest way to get up and running

anmonteiro17:03:18

I hope they welcome it :slightly_smiling_face:

anmonteiro17:03:26

it would definitely make things easier for us

anmonteiro17:03:13

@dnolen just went ahead and ported every spec fix in Clojure 1.9.0-alpha15 to ClojureScript

anmonteiro17:03:02

I think there will be a conflict between 1978 and 1980

dnolen17:03:41

@anmonteiro nice!

anmonteiro17:03:02

in any case the new macro mres will be duplicated if there are no conflicts

anmonteiro17:03:11

so probably need a better solution there

anmonteiro17:03:15

just so you’re aware

martinklepsch20:03:44

@anmonteiro Figured out how to build/install closure-compiler locally but the latest hoisting fixes apparently were not related to what I was seeing. https://github.com/google/closure-compiler/issues/2373