$ lein with-profile +cljs run -m shadow.cljs.devtools.cli
=>
exception in thread "main" java.lang.UnsupportedClassVersionError: shadow/build/closure/ErrorCollector has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0, compiling:(shadow/build/classpath.clj:1:1)

I’ve already upgraded to java 9 and downgraded again

Is it possible to override the hot reload WS URL?

I want to use a reverse proxy

@theasp by default the the websocket uses the url of the page itself + the default port of 9630

so if you serve the page over the proxy and also proxy 9630 that may work?

@denik hmm I switched to Java9 yesterday. are you on the latest release? maybe that broke older versions which it shoudln’t have

@denik I just published [email protected] which has class file version 52 again. (actually fixed in [email protected], sorry about that)

I'm trying out shadow-cljs and its working great so far. However I'm having problems getting the repl working correctly with cursive. I connect to the nrepl using cursive remote configuration. When i try to load a empty namespace its working ok, but when I load a simple namespace with some requires i get: CompilerException clojure.lang.ExceptionInfo: Call to clojure.core/ns did not conform to spec

@larshelg welcome. that sounds like you are maybe loading a ns with (:require ["a-string" ...]) as clojure code instead of cljs?

switching between clj/cljs is bit cumbersome in cursive

Hey, thanks for the welcome 🙂

Well I start up the repl in cursive, the connection seems fine.

Connecting to rempte nREPL server....

Clojure 1.9.0

then i load a simple namespace

i have to switch from clj to cljs in the repl config bar

when you connect to Cursive the REPL starts out of CLJ. so everything you eval is eval’d as clojure

true

you then need to start a build “watch”

but i thought it would be enough to switch to cljs in the toolbar....

either via the command line shadow-cljs watch the-build or via the REPL itself (shadow.cljs.devtools.api/watch :the-build)

you then need to switch the nREPL connection itself over to CLJS by selecting which build you want to talk to

(shadow.cljs.devtools.api/nrepl-select :the-build)

at this point the eval happens in CLJS

switching the cursive CLJ/CLJS option only controls the editor part

it does not interact with the REPL connection itself

i see, i'll try that then 🙂

i can sart the cursive repl before the shadow-cljs watch the-build?

i thought i had to start the watch build first...

shadow-cljs has a server mode which will start the nrepl server

one way to start the “server” is running shadow-cljs watch the-build

that starts the server AND watches the build

you can also just run shadow-cljs server or shadow-cljs start

that just starts the server and lets you do everything else independently

i see, so far i only started with shadow-cljs watch "build"

that is ok. then the build is already running

(shadow.cljs.devtools.api/nrepl-select :the-build) would be enough then

the nrepl can also completely control the server, that is why it starts out as clojure

colin is working on a REPL rework for Cursive which hopefully makes things a little easier to work with

After running the (shadow.cljs.devtools.api/nrepl-select :server) the repl still complains about not being able to load clojurescript in a clojure repl

I then try to change to clojurescript in the toolbar and load the namespace

try something simple like (js/alert "foo")

the namespace loades ok, so thats good

but when i do a (in-ns 'shadowpusher.core)

i get Thes i no connected JS runtime

which seems weird, since the watch build is running, and everything else seems fine...

yeah the alert gives same thing "no connected js runtime"

no connected runtime means that you have not yet loaded the page in the browser

when building for the browser

its a node build...

or started the node process

if you connect to a build you are responsible for running it

aha yeah i havent started the node process..

you can run shadow-cljs node-repl and (nrepl-select :node-repl)

that starts a node process automatically without a specific build

but builds do not start any node processes

its all working now, thanks for the help @thheller

@thheller yup downgrading shadow-cljs worked. Will try .137. Thanks!!

@thheller figwheel allows me to set :websocket-url to <wss://example.com/figwheel>, and the proxy sends that URL to figwheel. This way I don't need to make random ports public and can control access in one spot. I'd like to do the same with shadow-cljs

sure I can add that

Awesome!

there is just one issue

should be easily solved if you proxy correctly though

the websocket url takes parameters

I don't think they are affected

Sente uses paramaters too

well the parameters are in the path

Ohh! Yeah, no problem

/ws/*

can’t remember why I used the path instead of query args

either way if you set :websocket-url "" and forward /shadow-cljs/* to host:9630 that should be fine

(it also does some XHR requests for file reloading)

@theasp [email protected] lets you configure :devtools-url "". must be http or https, it will use ws where approriate.

as long as /* is forwarded to the actual shadow-cljs instance that should work

what are you using as proxy?

:builds {:build {:devtools {:devtools-url ...}}}} that is

thinking about it I could probably move that to the top level to make things easier

Awesome! TYVM, I'm using nginx. I can give you an example if you want one

@thheller trying to eval the ns form into the repl I get

CompilerException clojure.lang.ExceptionInfo: Call to clojure.core/ns did not conform to spec:
In: [1] val: ((:require [rum.core :as rum] ["d3" :as d3])) fails spec: :clojure.core.specs.alpha/ns-form at: [:args] predicate: (cat :docstring (? string?) :attr-map (? map?) :clauses :clojure.core.specs.alpha/ns-clauses),  Extra input
 #:clojure.spec.alpha{:problems [{:path [:args], :reason "Extra input", :pred (clojure.spec.alpha/cat :docstring (clojure.spec.alpha/? clojure.core/string?) :attr-map (clojure.spec.alpha/? clojure.core/map?) :clauses :clojure.core.specs.alpha/ns-clauses), :val ((:require [rum.core :as rum] ["d3" :as d3])), :via [:clojure.core.specs.alpha/ns-form], :in [1]}], :spec #object[clojure.spec.alpha$regex_spec_impl$reify__2436 0x1f563fb3 "clojure.spec.alpha$regex_spec_impl$reify__2436@1f563fb3"], :value (dashboard.core (:require [rum.core :as rum] ["d3" :as d3])), :args (dashboard.core (:require [rum.core :as rum] ["d3" :as d3]))}, compiling:(/Users/den/Dropbox/dev/code/centriq/centriq-automation/transcription/dashboard/src/dashboard/core.cljs:1:1) 

it’s because of the string "d3"

^ this is using proto-repl

@thheller DEVTOOLS: REPL init successful 🙂

@thheller https://gist.github.com/theasp/92b36733846be7dc0ed78840d3a3515a

@theasp neato.

@denik that looks like it might be trying to eval in clojure still. clojure doesn’t support the strings.

I don’t know much about proto repl

hmmm just did a quick test. it seems to connect fine but I can’ get it to eval anything

it sends a bunch of stuff it shouldn’t be sending 😞

When using the :npm-module target (https://shadow-cljs.github.io/docs/UsersGuide.html#target-npm-module), is it possible to somehow embed a REPL server into that outputted JS file? I'm trying to embed it into a create-react-app application, and then connect to it from CIDER :thinking_face:

yes but you need to shadow.cljs.devtools.client.node ns somehow

since :npm-module doesn’t have clearly defined entries

require("shadow-cljs/shadow.cljs.devtools.client.node") should do it if you are using the default :output-dir

eg. in the generated index.js

create-react-app makes things a bit tricky since its using ES6 import which can’t be conditional

otherwise I’d recommend wrapping the require in the usual process.env.NODE_ENV check

Ah ok. Maybe code splitting could help here? https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#code-splitting

I'm actually setting :output-dir to node_modules/shadow-cljs

To gain access to it using require

I’d recommend just rewriting the index.js to require

it has been a while since I messed with CRA

https://github.com/thheller/shadow-cljs-examples/tree/master/cljs-react-app

You mean add require("shadow-cljs/shadow.cljs.devtools.client.node") to App.js?

https://github.com/thheller/shadow-cljs-examples/blob/master/cljs-react-app/src/index.js

thats what I did back then

oh wait right .. not the node thing. require("shadow-cljs/shadow.cljs.devtools.client.browser");

Those links are great, thank you. I see you also set :runtime to :browser

In the shadow-cljs.edn file

CRA was the first project I used as a proof of concept for the integration

https://www.youtube.com/watch?v=BLDX5Twt2zk

May 21, 2017 … lots has changed since then

and the live reloading of CRA often completely messed up the REPL

not sure if that situation improved on the CRA side

is there a doc somewhere that explains what shadow-cljs is doing? you mentioned transpilation in the other thread. i’ve just gotten my head around why we have externs and how to avoid them with cljs-oops but it sound like shadow is doing something else. (the docs on how to use shadow are great, btw, kudos, i just like to have an idea of what the tool is actually doing)

wrote a whole series about Js dependencies here https://code.thheller.com/

nice thanks. this looks like it was written for me 🙂

https://code.thheller.com/blog/shadow-cljs/2017/11/10/js-dependencies-in-practice.html

@thheller once I have shadow.cljs.devtools.client.browser loaded, how would I start a REPL client? Something like: shadow-cljs cljs-repl?

yes, wrote a whole section about that a few hours ago https://shadow-cljs.github.io/docs/UsersGuide.html#_clojurescript_repl

@lee.justin.m I can go into technical details if you’d like. I mostly left those out and focused more on the “why”

but in essence it is doing the exact same thing webpack and others are doing

@thheller My basic curiosity is that I’m a javascript programmer. Things like webpack and minification and babel all screw with the code and seem to be able to do so without breaking everything. So far I’m a little curious and terrified that certain kinds of innocuous code (.field js/thing) can be broken so easily. How do other tools do it? So my interest in (1) the practical, which so far has been: use cljs-oops for all external accesses and (2) learn about different approaches people are taking. It seems like you are doing something different in shadow to make interop safer (?). At any rate I just have a general technical curiosity here. No specific burning need.

I don’t recommend using cljs-oops at all. shadow-cljs has greatly improved externs inference support which has elimitated the need for almost every extern I used before

https://code.thheller.com/blog/shadow-cljs/2017/11/06/improved-externs-inference.html

basically I run everything with :infer-externs :auto these days

very occasionally I add a typehint

things like (.field js/thing) are fully inferred

Regarding this: We only need externs for the code we actually call from CLJS, not everything the JS code uses. That suggests that over-specifying externs keeps code in that might otherwise be elided. Does GCC do DCE on npm modules? I thought the whole idea is that the compiler won’t do advanced optimizations on npm modules and the externs are a directive to the compiler not to name mangle those symbols in optimized code.

no, shadow only does :simple for everything on node_modules.

but the CLJS/goog parts still run through :advanced

so at the interop points you need externs

but since shadow now knows more about those interop points due to the requires in ns and such

it can do better externs inference for those

I was just trying to figure out why exactly too many externs increases code size.

the increase is minimal

but say you have createThing defined somewhere in the externs

the closure compiler will now protect that name whenever it can’t exactly identify which type it is on

since CLJS is untyped that basically means always

so createThing will never be shortened or removed, even if it could be otherwise

it doesn’t really matter i guess but given that the javascript module is going through :simple optimizations i was think that createThing couldn’t ever be renamed or removed anyway

yes, only very basic code removal is done for node_modules

but CLJS is still fully :advanced optimized so it could be removed there (in case it exists)

the goal is to run everything through :advanced at some point

thats what CLJS tries to do .. but it just isn’t reliable enough yet.

This great stuff. I’m going to read through your stuff before I ask you any more questions. 🙂

most of it should be covered in some form

feel free to ask though. always helps to validate that I’m not doing crazy things 😉

I do have one other question, which is actually about DCE. Do you know if the symbol munging thing is necessary to do DCE? I’ve often wondered if we could just turn on DCE without the symbol munging and get some stuff for free.

the munging no but the collapse

in CLJS (or closure) everything is namespaced

so if you have (ns demo.app) (defn foo [])

you get a demo.app.foo = function() {} basically

closure collapses this down to demo$app$foo so it can remove the nested objects

this collapse is necessary for DCE (AFAIK)

the rename then just shortens it down to something like xA (or removes it entirely)

the closure compiler has some options that let you fine tune what it does to the code

disabling variable renaming or property renaming is an option

but if you disable too much you basically end up at :simple

which is still better then uglifyjs but nowhere near :advanced

i see

closure is already pretty good at optimizing ES6. it just struggles with some dynamic CJS things people do

hopefully more JS people will begin publishing more ES6 code

slow procress I guess if node can’t even decide how to do proper es6 interop

it would be interesting if you could do static analysis on a body of code to try to see if code was already safe for advanced optimization. you’d get a lot of false positives, but it might be able to show you everywhere something dangerous is happening (e.g. string property access)

well you can always set :js-provider :closure and see if you code still works. that does :advanced for everything. if it doesn’t go back to :shadow.

full analysis might be painful given the dynamic nature of JS

yea it would probably not work in a lot of cases, but it would be awesome if you could use babel or something to provide certainty that a module is safe for compilation

anyway, i don’t even understand what the hell is going on at any level so that’s just a pipe dream

unfortunately babel is responsible for some of the breakage 😉

doing what webpack and babel do however seems to be the safest way to deal with node_modules so I’m doing that

well i’m interested to dig in. so far the safest route for using modules for me has been to use distribution builds with no externs and run all accesses through cljs-oops.

if you like cljs-oops by all means keep using it and reduce it gradually maybe

oh i’m not wedded to anything, but cljs-oops is better than relying on some half assed broken not up to date externs file that someone made 3 years ago

indeed

better yet use :infer-externs :auto and let the compiler tell you if it doesn’t unterstand something

whether you then use ^js typehint or cljs-oops as the fix is up to you