Fork me on GitHub
#cljs-dev
<
2017-01-21
>
anmonteiro00:01:08

does it respect index.js as the entry point for a lib?

anmonteiro00:01:21

(or is that something GClosure already does?)

dnolen00:01:22

if everything works as planned then you should be able to just specify a single :foreign-lib entry for .node_modules

dnolen00:01:31

@anmonteiro we shouldn’t need to do anything

juhoteperi00:01:36

Closure should be able to read entry point from package.json

dnolen00:01:48

Google Closure just needs to get everything as inputs

dnolen00:01:07

@juhoteperi I don’t think reading from package.json is necessary

juhoteperi00:01:20

It is needed if one wants to refer just library and get the main entry point

dnolen00:01:31

the only issue I ran into here is that I couldn’t get advanced compilation to work with Maria’s circle-demo, but it seems it doesn’t have anything to do with what I’ve done?

juhoteperi00:01:35

else there is no mapping from react -> lib/react.js or something

juhoteperi00:01:04

but hmm.. I guess this is not needed when requiring JS modules from Cljs

juhoteperi00:01:27

But Closure does this internally for dependencies between CommonJS modules

anmonteiro00:01:17

@dnolen what do you mean advanced compilation to work?

anmonteiro00:01:30

it should compile just fine, just the demo doesn't work as expected

anmonteiro00:01:43

^ if this is what's happening, it's expected

dnolen00:01:09

^ this is all you need to do - you don’t need to specify individual files

dnolen00:01:54

:foreign-libs :file just needs to be on classpath - then you can require anything from that like a normal CLJS dep

dnolen00:01:34

everything is written into :output-dir respecting the original path - so no clashes

anmonteiro00:01:39

👍 seems like we get the best of both worlds

dnolen00:01:55

and I think Figwheel will just work

anmonteiro00:01:07

i.e. no more weirdness about "do foreign libs need to be in the classpath?"

dnolen00:01:19

so mixing JSX, ES6 into a ClojureScript project should be a cinch

dnolen00:01:37

@anmonteiro right everything just follows the same conventions

anmonteiro00:01:51

this is awesome, can't wait to try it out

dnolen00:01:06

@anmonteiro right advanced compilation completes - but doesn’t work

dnolen00:01:15

dev mode works fine

dnolen00:01:21

but that’s to be expected

anmonteiro00:01:22

last time I looked at it was an externs problem

anmonteiro00:01:33

@juhoteperi btw would also probably be cool to have some version of this in CLJSJS

juhoteperi00:01:15

it is missing at least externs for svg properties, like cx, cy and maybe fill

anmonteiro00:01:33

if you really want advanced to work, try adding those externs

dnolen00:01:38

hrm maybe it can just work - but I’m tired of working on it at the moment 🙂

dnolen00:01:44

happy to see other people try it out 🙂 🙂 🙂

dnolen00:01:12

enumerate-namespace is toast - you can just specify a namespace instead of a symbol

dnolen00:01:33

probably the only other thing I’m going to look at before cutting a release is return type propagation for externs inference

dnolen00:01:48

so if you really want some ticket to make into the next release let me know - shooting for next Friday

darwin00:01:23

I would vote for http://dev.clojure.org/jira/browse/CLJS-1075, not sure how hard it would be, it is already implemented in bootstrapped: http://dev.clojure.org/jira/browse/CLJS-1354 reason: just started working on support for nodejs development in Dirac DevTools[1], sourcemaps filesystem “links" are understood by nodejs, but DevTools cannot access them directly on filesystem, inlined smaps would solve it [1] https://github.com/binaryage/dirac/issues/31

darwin00:01:46

but it does not have big priority, current workaround is to spawn a web server to serve source-maps, it is just tricky to setup paths/urls to properly match for average joe

dnolen00:01:08

@darwin that would also fix the timestamp hacks - I’m not going to have time to work on that myself

darwin00:01:10

took me a while to get it workingf 🙂

dnolen00:01:36

a patch that delivers a new compiler option :inline-source-maps is welcome

dnolen00:01:53

then after it’s proven to work it could be enabled as default in the future

darwin00:01:37

ok, I will try to look at it

dnolen00:01:59

also I’m pretty sure we don’t want that option for anything but optimizations :none

darwin00:01:49

I barely recall that closure compiler has also some new options to produce combined source maps and optionally inline them

dnolen00:01:11

yes they have something, but I haven’t had anytime to look at it

dnolen00:01:19

if we could replace our stuff for doing that, that would be great

dnolen00:01:38

but that should be a separate task/ticket

darwin00:01:56

that could cover :advanced and :simple cases, I don’t think closure compiler is involved in :none, right?

dnolen00:01:20

as long as it does cover it sure - I don’t know how comprehensive or good it is

mfikes00:01:02

I’d vote for these two: http://dev.clojure.org/jira/browse/CLJS-1873 (making self-host tests great again) http://dev.clojure.org/jira/browse/CLJS-1874 (a quirk discovered with self-host, :fn-var analysis, and macros)

dnolen00:01:47

@mfikes thanks added to my queue

dnolen19:01:04

@bhauman let me know when you get a chance to get Figwheel working with this stuff - I’ve got a blog post brewing 🙂

darwin22:01:00

looks like :source-map-asset-path compiler option works, except for core.cljs, where is ignored for some reason, investigating...

darwin22:01:01

not reproducible in current master, but present in 1.9.293 - I assume opts wasn’t passed properly into emit-source-map in some edge case

dnolen22:01:48

@darwin yeah, I audited the code and made sure we are consistently passing compilation opts around if bound