Clojurians
#cljs-dev
<
2018-11-09
>

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

mfikes14:11:33

An issue to be sorted: Quick Start page should be updated to 1.10.439, but we don’t have a standalone cljs.jar for that release.

dnolen14:11:25

huh I thought I uploaded that

dnolen14:11:41

hopefully fixed now

borkdude17:11:06

maybe for cljdoc you can override 439 with 339 as a temp workaround?

martinklepsch17:11:15

I'll wait what ClojureScript maintainers say, usually turnaround on this kind of issue is pretty fast so maybe fine to wait.

martinklepsch17:11:44

And just using 339 could cause issues with users who use new stuff from 439 (assuming there is new stuff)

martinklepsch17:11:07

I'm somewhat surprised that this didn't come up before though. Not sure I understand but wouldn't this affect everyone using 1.10.439 and orchestra?

borkdude17:11:48

I have been using 439 with speculative and didn’t see the issue at runtime.

borkdude17:11:04

our tests run with JVM cljs and self-hosted

martinklepsch18:11:21

Unfortunately it seems like *analyze-deps* was rather important to be able to analyze namespaces that require react and similar

borkdude18:11:11

sorry I sent you down a rabbit hole

martinklepsch18:11:25

haha, no worries :smile:

dnolen17:11:00

@martinklepsch this issue doesn't really make any sense to me

dnolen17:11:08

I don't see how this could have anything to do w/ the analyzer

dnolen17:11:19

but I'm assuming that your gist is a minimal repro?

martinklepsch17:11:14

@dnolen the gist shows how ana/analyze-file throws an exception in 439 that isn't thrown in 339

martinklepsch17:11:54

my description (macros, dynvars etc.) might be absolutely wrong, those are more guesswork

dnolen17:11:48

@martinklepsch yeah that won't work

dnolen17:11:11

if it did work before, you were getting lucky

dnolen17:11:35

if you analyze a file with analyzing deps you won't load macros

dnolen17:11:38

so it won't work

mfikes17:11:01

Also, if you set *analyze-deps* to true it works.

dnolen17:11:14

that will actually load the files

dnolen17:11:21

so I wouldn't consider this a regression

martinklepsch17:11:43

duh, interesting I just copied that *analyze-deps* thing mindlessly

martinklepsch18:11:27

Thanks, and sorry for the false alarm :sweat_smile:

martinklepsch18:11:50

I changed *analyze-deps* to true but now I'm having issues analyzing any namespace that transitively requires something like cljsjs.react — is there something special that needs to be done for this to work?

No such namespace: cljsjs.react, could not locate cljsjs/react.cljs, cljsjs/react.cljc, or JavaScript source providing "cljsjs.react" in file file:/Users/martinklepsch/.m2/repository/reagent/reagent/0.7.0/reagent-0.7.0.jar!/reagent/impl/util.cljs {:tag :cljs/analysis-error}

dnolen19:11:29

you need to provide foreign deps entries for that stuff

dnolen19:11:40

since you can't resolve directly via the classpath

dnolen19:11:00

@martinklepsch ^

martinklepsch19:11:19

@dnolen do build tools handle this by scanning the classpath for deps.cljs? I guess I'll need to implement this in a generic way somehow (i.e. classpath->foreign-deps-entries) — if you have any pointers around that I'd appreciate them :slightly_smiling_face: