shadow-cljs 2018-06-03 | Slack Archive

hm i just tried and it seems to work for me

i tried the same files structure as what yo uare doing

@wilkerlucio try the latest version. previously errors in JS file ended up in the wrong place so you'd get confusing errors like The required JS dependency ... instead of actually showing the error in the file. It most likely just has a parse error.

thheller07:06:47

please open an issue about the tether thing. will need to check it out later.

thheller07:06:00

@wilkerlucio there is a weird problem currently for cljs files including JS files in the classpath root. CLJS does not like namespaces with one segment. so src/file.cljs is bad. try src/thing/file.cljs instead so at least one level nested. JS file should be nested with it. Generally everything on the classpath should be properly scoped as you'd otherwise just get into trouble with dependency conflicts.

Geoffrey Gaillard09:06:41

I got stuck with an issue combining datascript and shadow-cljs in :release mode. Turns out it was caused by a missing extern as in :compiler-options {:externs ["datascript/externs.js"]}. I didn't got the issue with cljsbuild, so I suppose the extern was automatically injected, moreover this detail is not mentionned in the datascript documentation. Is there a reason shadow-cljs behave differently regarding externs ?

thheller09:06:57

maybe accidental? were you using many cljsjs packages before?

Geoffrey Gaillard09:06:14

Indeed ! it was my #1 reason to migrate to shadow: getting rid of cljsjs 🙂

thheller09:06:41

since they often package generated externs maybe one of those accidentally "fixed" the datascript issue

thheller09:06:07

it doesn't really matter where a property is defined in the externs, as long as it is defined somewhere

thheller09:06:43

ah ok nvm datascript includes the externs via deps.cljs

👍 4

thheller09:06:13

I have support for that disabled, should probably add a compiler option to enable it

Geoffrey Gaillard10:06:56

Is it pertinent to provide an option ? As far as I can tell, I've never seen a use case where not providing an extern was a solution. Wouldn't be enough to perform a (set/union …) of all available externs ? Wherever they comes from a file A or a file B ?

thheller10:06:06

the reason I disabled them is because 99% of the time they are not required

thheller10:06:39

and providing too many externs may be bad for :advanced since it can't remove anything that is mentioned in externs

thheller10:06:53

so you could end up with more code staying alive then desired

👍 4

thheller10:06:08

datascript is the first case I heard where this is a problem

wilkerlucio15:06:25

@thheller thanks! makes sense, I was trying in a single namespace (`cljsjs`), seems using more works fine

wilkerlucio15:06:04

about the warnings, is there something I can do to dismiss then on the screen? I'm porting this big project, and warnings from dependencies are making the page unusable after reloads

wilkerlucio15:06:41

what about having a UI that only shows one warning, and can navigate via buttons (arrows) across the errors, and with an X to just close then, I can work on this

thheller16:06:09

@wilkerlucio open an issue please. won't get to it before tuesday though.

thheller16:06:44

I think it would be best to put all warnings in a separate container with overflow: scroll; so it doesn't go beyond a certain height

wilkerlucio16:06:16

yeah, make it dismissable

wilkerlucio16:06:31

I was thinking about something more interactive, but in a container can be easier

2018-06-03

Channels