after updating to shadow-cljs 2.4.30, the I get an empty .nrepl-port, and shadow-cljs server shows shadow-cljs - nREPL server started on port (no port shown). the shadow-cljs.edn is very simple:

{:dependencies [[zprint "0.4.10"]
                [funcool/cuerdas "2.0.5"]]
 :source-paths ["src"]
 :builds {:test2 {:target :node-script
                  :main fmtz2.core/main
                  :output-to "out/test2.js"}}}

going back to 2.4.28 works fine

@samuel.wagen there should be a warning printed on startup if nrepl fails?

shadow-cljs - config: /Users/bupkis/dev/test2/shadow-cljs.edn  cli version: 2.4.30  node: v10.8.0
shadow-cljs - starting ...
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.xnio.nio.NioXnio$2 (file:/Users/bupkis/.m2/repository/org/jboss/xnio/xnio-nio/3.3.8.Final/xnio-nio-3.3.8.Final.jar) to constructor sun.nio.ch.KQueueSelectorProvider()
WARNING: Please consider reporting this to the maintainers of org.xnio.nio.NioXnio$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
shadow-cljs - server version: 2.4.30
shadow-cljs - server running at 
shadow-cljs - socket REPL running on port 55789
shadow-cljs - nREPL server started on port

only warnings are the JDK10 ones in xnio

but I get those with working versions too

oh right nevermind. I just broke it

🙂

@samuel.wagen should be fixed in 2.4.31

it now starts the nrepl server, but when I do (shadow/node-repl) from Cursive - I get RuntimeException Can't resolve find-ns clojure.lang.Util.runtimeException (Util.java:221)

what the heck

https://github.com/thheller/shadow-cljs/issues/273

this used to only happen with cider

no cider in this particular project

do you have the full stacktrace?

cursive isn't showing it to me

let me try outside of cursive

hmm that only happens in cursive

if i start the server, and in another terminal do shadow-cljs clj-repl and from that I do (shadow/node-repl) - I get to the CLJS repl no problem

but in cursive - the above error. going back to 2.4.28 fixes it

yeah the problem lies in nrepl

it is doing something with the classloader

intellij is 2018.2, cursive is 1.8.0-eap4-2018.2 if that matters

no its a shadow-cljs side problem

or rather nrepl server side

could it be connected to another problem I'm having with versions >2.4.28? it also has issues in a project where I use refactor-nrepl (`[WARNING] No nREPL middleware descriptor in metadata of #'refactor-nrepl.middleware/wrap-refactor, see nrepl.middleware/set-descriptor!`), but I guess that's not a shadow issue, more of an issue between the new nrepl and refactor-nrepl

cider-nrepl as of 0.18.0 uses nrepl 0.4

I'm not sure if there is a refactor-nrepl upgrade out yet

but I said you use cursive? why the middleware then?

I said above it's in a different project, just thought it could be related since it started in >2.4.28 too.

sorry for confusing you

the entire problem is due to nrepl 0.4 not being compatible with 0.2

so libraries written for 0.2 stop working

cider had a new release yesterday for 0.4

but Cursive perhaps isn't supporting 0.4 yet?

cursive doesn't care

it doesn't use any middleware so it works either way

but it still uses nrepl?

ah so only the middlewares are having issues, not vanilla nrepl clients

yes

clients are unaffected since the nrepl messages didn't change

but shadow is affected (in the cursive case) somewhat?

it seems to work for me. I cannot reproduce the find-ns problem

weird. let me blow away the .shadow-cljs directory and try again. the config is above - very vanilla

ah got it

hehe what the actual F*$#

I tracked the problem down to tools.logging a while ago but thought it was just masking a different underlying issue

I now fixed the tools.logging issue

and the problem goes away

ha, it really is a wtf

why does tools.logging mess with the class loader

https://groups.google.com/d/msg/clojure-dev/mRWujdKmtmE/exjJCZFkAgAJ

so tools.logging uses *ns* all over the place which results in this find-ns call

WHY exactly it fails I have no idea

so I'm really just treating a symptom when fixing tools.logging

the underlying issue I have not yet identified

that thread is ridiculous, why are they being so stubborn to even acknowledge the issue, not to mention accept a fix

I shouldn't have made it about load time ... and really should have just started by patching tools.logging instead

which I'll replace now I guess

Hi, i’ve just done a release build and it’s pretty obnoxiously large (~5Mb) , is there any way to figure out what the contributors are ?

@eoliphant https://shadow-cljs.github.io/docs/UsersGuide.html#_build_report

duh 🙂 cool thanks.

Hm.. I'm getting a warning cljs.core.ICounted is not a protocol when trying to implement a record with custom counting, however my tests seem to show that it's working correctly. Am I missing something?

cljs.core/ICounted

Duh

thanks

well maybe. not actually sure 🙂

@samuel.wagen the find-ns issue should hopefully be fixed in 2.4.32. I can no longer reproduce it at least.

@thheller yep, works perfectly, vielen Dank

anyone using the aws-sdk? It’s adding like 2Mb to my build, I’m only requiring the following

["aws-sdk" :default AWS]
    ["aws-sdk/clients/s3" :default S3]

hmm aws seems to import a crapton of JSON files

it may work if you do

["aws-sdk/lib/util" :as AWS]
    ["aws-sdk/clients/s3" :as S3]

if you import aws-sdk it'll bring in every single thing including the stuff you don't actually use

so you should awlays try to only require what you actually need

^ @eoliphant

I’m trying to use shadow-cljs in a small project which uses some npm modules that I want to require in my ClojureScript code. I’m using Emacs with CIDER and followed the instructions on https://shadow-cljs.github.io/docs/UsersGuide.html#cider to start a server and connect to the repl, but running M-x cider-connect times out with the error:

[nREPL] Establishing direct connection to localhost:55098 ...
[nREPL] Direct connection to localhost:55098 established
helm-M-x: Sync nREPL request timed out (op clone id 1)

@samarthkishor1 I don't know anything about cider unfortunately

@thheller I’ll try posting this in the cider channel then. Thanks for the response!

cider is in this weird spot right now due to the nrepl 0.4 migration. are you on 0.18.0 already?

I tried my best at supporting both nrepl versions but that has proven to be much harder than anticipated

may be related to this though

I upgraded to the latest version of cider this morning and the dependencies section of my shadow-cljs.edn file looks like this:

:dependencies [[cider/cider-nrepl "0.18.0"]]

are you on the latest shadow-cljs too?

fixed a few related bugs just today

I installed it yesterday from npm but I can try the latest version

2.4.32 should hopefully fix most issues

I got the repl to run but I can’t send expressions to the repl from a cljs buffer or evaluate them. At least I have something to work with though. Thanks!

don't forget about all of this https://shadow-cljs.github.io/docs/UsersGuide.html#_launch_the_clojurescript_repl

no idea how current that is though

M-x cider-create-sibling-cljs-repl doesn’t seem to be a command. I’ll look in the cider docs to see if it got renamed to something else

updated to 2.4.32 and getting this:

<< Building for release >>
[:mp360] Compiling ...
The required namespace "doublethedonation.integrations.app" is not available.

[:ddregister] Compiling ...
The required namespace "doublethedonation.register" is not available.

[:ddplugin] Compiling ...
The required namespace "doublethedonation.external" is not available.

[:mp360partners] Compiling ...
The required namespace "doublethedonation.partner-portal.app" is not available.

downgraded to .31 and it works fine

hmm thats odd. nothing changed regarding compilation. only logging stuff.

@kanwei how are you calling things? << Building for release >> looks like something custom maybe?

https://gist.github.com/kanwei/26c0da2c47278f598f5e02fa8a543c87

calling it with

(cljs/release :builds #{:mp360 :mp360partners :ddregister :ddplugin})

hmm I don't know boot, can you try it without boot?

the errors sugguests that maybe the classpath isn't configured properly. but nothing changed regarding that in 2.4.32

@kanwei could you maybe try with http://github.com/degree9/boot-shadow

it was originally based on that gist (or a similar one)

alternatively try with the standalone cli app as @thheller suggests

oh heck I know what it is

I dropped the java.classpath dependency and its single use

which I guess boot relies on

totally forgot about that. I'll revert that change.

@thheller where was that modified? Is this something I can patch in the boot task directly?

can boot set the java.class.path property?

@thheller boot does I believe as it abstracts the actual classpath with a virtual one, via the fileset concept

https://github.com/boot-clj/boot/wiki/Filesets

yes but shadow-cljs needs to read the classpath

since it can't do that by looking at the classloaders in Java9

it does that by looking at the system property java.class.path

and I removed the "old" stuff which looks at the classloader

but I guess boot really needs that

https://github.com/thheller/shadow-cljs/commit/e9bd399ab82f9ac826f880ab51a50f67bac5783f

@thheller we should be able to provide a class path, since boot requires building it’s own

https://github.com/boot-clj/boot/blob/master/doc/boot.pod.md#get-classpath

this should fix it

@kanwei try 2.4.33, sorry about that. didn't think anyone was relying on that old behaviour since it doesn't work in java9+

@flyboarder does boot work with java9+?

yep all the way to Java 11

but how do you get the classpath from in side a pod?

(boot.pod/get-classpath)

well I can't add boot specific api calls to shadow-cljs

right, so we need to be able to pass a classpath to shadow-cljs config

I guess you could replace the shadow.build.classpath/get-classpath fn with something that calls the boot thing?

or we can build the pod using an existing classpath from shadow

@thheller ^

the gist already has a prepare-runtime fn that seems to do some stuff

you could try

(in-ns 'shadow.build.classpath)

(defn get-classpath []
  (boot.pod/get-classpath))

but you can open an issue about the classpath via config thing

should be easy enough to hook up

where is the shadow class path being constructed?

I wonder if I can just use that?

what do you mean?

Is it just checking the property? or does it build it’s own?

the shadow-cljs npm command builds the classpath and starts with JVM with it set

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/classpath.clj#L35-L43

this then reads that

@alandipert Do you know of a way to fix this classpath issue above? Ideally I’d like to just patch it within a boot task to the shadow pod

@thheller I’ll keep looking into this and see if I can patch it from the boot task instead of requiring changes to the internals of shadow

from what I know its no longer possible to inspect the classpath by looking at classloaders in java9+

only with very ugly reflection warnings which I don't want

Boot has to be doing something that makes this possible 😛

but that might not actually be true. so if someone knows a way to still do it in java9+ I'm happy to consider it

@flyboarder its only a problem is something actually tries to inspect the classpath. you don't usually have much reason to do so

https://github.com/boot-clj/boot/issues/691

those are the reflection warnings I want to avoid

https://youtu.be/4fevIDAxQAM?t=13m26s

@thheller looks like there was an issue open to add boot class path support to external tools, a quick check for boot.class.path could also do the trick

is that documented somewhere? impossible to google

@thheller https://github.com/boot-clj/boot/issues/249

https://github.com/boot-clj/boot/blob/59909f135871af4a8ae82bda3268e8816b238e36/boot/core/src/boot/core.clj#L142-L158

ok I can add the extra check for that

tomorrow though. off to bed. gn8

@kanwei can you post your boot environment also? Does it include the source folders that are also in shadow-cljs.edn?