Fork me on GitHub
#shadow-cljs
<
2018-12-18
>
manuel08:12:46

hi guys, upon starting shadow-cljs watch :my-app, I am getting this:

[2018-12-18 09:39:02.276 - INFO] Using tools.nrepl 0.2.* server!
This is my shadow-cljs.edn:
{:source-paths ["src/cljs"]
 :nrepl {:port 8777
         :middleware [refactor-nrepl.middleware/wrap-refactor]}
 :dependencies [[bidi "2.1.4"]
                [binaryage/devtools "0.9.10"]
                [cider/cider-nrepl "0.18.0"]
                [cljs-ajax "0.8.0"]
                [clojure-humanize "0.2.2"]
                [com.cemerick/url "0.1.1"]
                [hickory "0.7.1"]
                [day8.re-frame/http-fx "0.1.6"]
                [kibu/pushy "0.3.8"]
                [macchiato/hiccups "0.4.1"]
                [re-frame "0.10.6"]
                [reagent "0.8.1"]
                [reagent-utils "0.3.1"]
                [refactor-nrepl "2.4.0"]]
 :builds {:my-app {:target :browser
                   :output-dir "resources/public/js"
                    :asset-path "/js"
                    :modules {:main {:entries [my-app.core]}}}}}
Any ideas? ๐Ÿ™‚

thheller09:12:05

@manuel what is the problem?

manuel09:12:56

I'm not sure it's related, but I get these warnings when I do cider-connect:

WARNING: CIDER requires nREPL 0.2.12 (or newer) to work properly
         More information.
WARNING: Can't determine Clojure's version. CIDER requires Clojure 1.8.0 (or newer).
         More information.
WARNING: CIDER requires cider-nrepl to be fully functional. Many things will not work without it!
         More information.

manuel09:12:46

(I cross-posted this problem in #cider, because I don't know to what it's related TBH)

thheller09:12:43

and you are on cider 0.18 on the emacs side?

manuel09:12:38

nope, CIDER 0.19.0snapshot (package: 20181212.1936). But even using [cider/cider-nrepl "0.19.0-SNAPSHOT"] in shadow-cljs.edn doesn't fix it.

thheller09:12:36

are you sure? did you restart properly after changing it? AFAICT the versions need to match

manuel09:12:50

let me try again

thheller09:12:44

and are you sure you are connecting to 8777? not using some other built-in nrepl mechanism that starts something via deps.edn? since you mentioned that

manuel09:12:00

same warnings

manuel09:12:11

no, I explicity input the port 8777

manuel09:12:56

I restarted Emacs, just to be sure, but the warnings are still there.

thheller09:12:12

and what startup message did you get?

thheller09:12:19

[2018-12-18 09:39:02.276 - INFO] Using tools.nrepl 0.2.* server!

thheller09:12:23

this should be gone right?

manuel09:12:30

no still there

thheller09:12:40

that should definitely be gone though

manuel09:12:43

note that on another project with [cider/cider-nrepl "0.18.0"] I haven't got neither the message nor the warnings after CIDER connect.

manuel09:12:16

โฏ shadow-cljs clj-repl
shadow-cljs - config: /home/manuel/githubs/manuel-uberti/boodle/shadow-cljs.edn  cli version: 2.7.9  node: v8.14.0
shadow-cljs - starting ...
Dec 18, 2018 10:45:14 AM org.xnio.Xnio <clinit>
INFO: XNIO version 3.3.8.Final
Dec 18, 2018 10:45:14 AM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.3.8.Final
shadow-cljs - server version: 2.7.9
shadow-cljs - server running at 
shadow-cljs - socket REPL running on port 36281
shadow-cljs - nREPL server started on port 8777
shadow-cljs - REPL - see (help)
To quit, type: :repl/quit
[1:0]~shadow.user=> (require '[ :as io])
nil
[1:0]~shadow.user=> (io/resource "cider/nrepl.clj")
#object[java.net.URL 0x324afa73 "jar:file:/home/manuel/.m2/repository/cider/cider-nrepl/0.18.0/cider-nrepl-0.18.0.jar!/cider/nrepl.clj"]

thheller09:12:50

[com.cemerick/austin "0.1.3"]
  [com.cemerick/piggieback "0.1.2"]
    [org.clojure/tools.nrepl "0.2.3"]

thheller09:12:53

that should not be there

thheller09:12:23

not sure what adds that dependency

manuel09:12:35

let me check

thheller09:12:37

but it messed up cider.nrepl detection of which nrepl server to uise

manuel09:12:07

found it: macchiato/hiccups

manuel09:12:22

I'll exclude austin from it.

manuel09:12:00

fixed it, you're the man! ๐Ÿ™‚ Thank you!

davidw11:12:08

Hi. We have an app that uses a library, both app and lib are under our control, both have clj/cljs/cljc code. We use deps.edn and the app references the library with a git sha. We need to hand over the source code for the app to our client but not the source code for the library. On the jvm side I can create an aot compiled skinny jar for the lib. Is there something similar I can do on the javascript side so that I can still use the library, with no/minimal code changes, but without distributing the source?

thheller11:12:08

@davidw no that is not possible. CLJS compiler needs the full analyzer data to compile which it can only build from source

davidw11:12:18

I don't really know how the whole compilation process works so this may be a stupid question but would it not be possible to bundle up the js files that get generated during a dev build in cljs-runtime and then use them when compiling the app? The CLJS compiler has already generated js for those namespaces, no?

thheller11:12:07

no. the analyzer data is needed for namespaces that :require your lib

thheller11:12:29

and macros also make this complicated

thheller11:12:16

why is it so bad to ship the source code? its not exactly "secret" either with AOT compilation

thheller11:12:43

thats what licences are for after all

davidw11:12:32

I understand it's not "secret", etc. It's a constraint I've been given so it's what I'm trying to work within for now.

thheller11:12:38

yeah. It would not be impossible to do this but it would involve a bit of compiler work and nobody has worked on anything like that AFAICT

thheller11:12:59

and yeah macros make this extra tricky

davidw11:12:37

if you don't mind I'd like to pick your brains on it a little more. Leaving macros aside for now ๐Ÿ™‚. You've made it possible to :require npm modules and they obviously don't have the cljs analyzer data. In theory could something similar be done to :require the pre-compiled .js output?

thheller11:12:14

not really. the cljs compiler can only emit cljs code with the anaylzer data present

thheller11:12:27

if that is not present it can only emit js code relying on interop

thheller11:12:38

so stuff like protocols don't work for example (since they require analyzer data and don't exist in JS)

thheller11:12:18

it is really the analyzer data that is the problem

thheller11:12:34

the generated JS pretty much doesn't matter so that would work no problem

thheller11:12:49

but analyzer data may change inbetween cljs versions

thheller11:12:18

so you'd need the analyzer data for your-library-v1.3-compiled-by-cljs-1.10.439

thheller11:12:33

and every other possible cljs version the user may be using at the time

thheller11:12:59

it is possible ... just a bit of work

davidw11:12:27

If it's possible, how do you think you'd you solve it? Would you package up the analyzer data?

thheller12:12:24

yeah bundle the js+analyzer data. somehow teach to compiler to discover and use it

davidw12:12:54

ok, sounds like more than "just a bit of work" ๐Ÿ™‚

thheller12:12:55

it is definitely not a trivial bit of work yes

davidw12:12:22

So it seems my options are, compile the lib to js and use js interop which means quite extensive changes to the app code, or just distribute the source code in a jar.

thheller12:12:42

do you use any CLJS-only features in the lib?

thheller12:12:54

macros, protocols, defrecord, deftype, etc?

thheller12:12:16

if not you can maybe get away with just shipping the JS

thheller12:12:53

I never actually tried and it is not recommended to do so but in theory it could work as it will be treated as Closure JS, like the closure library itself and that works fine.

davidw12:12:29

how would I go about testing it?

thheller12:12:30

do a dev compile. take the files from the cljs-runtime dir for your lib only and put them into the classpath of the other app

thheller12:12:47

eg. your.lib.foo.js

thheller12:12:05

don't put the lib sources on the classpath of the app

thheller12:12:26

so that is only finds the js files (shadow-cljs will scan the classpath so make sure it doesn't contain the actual sources)

davidw12:12:16

ok, I'll try that, thanks.

thheller12:12:32

it will definitely not be ideal but it might work

thheller12:12:48

as long as there are no macros ๐Ÿ˜‰

davidw12:12:24

ok, do they need to be in namespaced subfolders on the classpath?

thheller12:12:57

no that doesn't matter for js files

davidw12:12:19

ok, thanks. I'll give it a try.

thheller12:12:21

they will contain goog.provide("your.lib") which is all it needs

Alex K15:12:41

Hi folks. Anyone have an idea how to require Grommet in from NPM? I think they're doing something a bit odd with the es6 module exports, but I don't have the experience to say what that is or figure a way around it. Thanks.

thheller17:12:21

what did you try?

Alex K18:12:21

[grommet :as g] at first. Nothing in g when I printed it in console other than that it was an es6 module. After that I looked at the index file the package.json indicated, and tried ["grommet/components" :as gc] ["grommet/contexts" :as gcon] ["grommet/default-props" :as gdp] ["grommet/themes" :as gt]. The latter three had relevant bits, but not components. Also tried pulling in components from the subdirectories, but everything I tried turned up undefined. I don't grok the exports stuff enough to know what else I should try.

thheller18:12:52

I get Cannot read property 'apply' of undefined when it tries to load the code

thheller18:12:28

not really sure whats happening but it has nothing to do with exports or how you require it

thheller18:12:33

it just fails to load module$node_modules$grommet$components$Box$Box

thheller18:12:08

ok what the actual F

thheller19:12:21

there is definitely something weird in the code ๐Ÿ˜›

lilactown19:12:16

their website is also slow as molasses

thheller19:12:39

sorry. not a clue what is happening here. completely clueless what is even going on in that code

Alex K19:12:06

Not a problem. I've been getting the feeling that library might not be dependable anyway. Thanks for trying, and thanks for shadow too. It's made things much easier.

ShaneLester20:12:21

Having a bit of trouble finding some info on this- is there a semi-painless way to have shadow use a different version of clojurescript? Essentially, there has been a commit to the cljs repo that fixes an annoying bug for me, and Iโ€™d like to give it a shot while also continuing to use shadow etc.

thheller20:12:06

@shanelester55 only if you use deps.edn or lein to manage your deps

ShaneLester20:12:21

Ahh I see. The dependencies section of the shadow-cljs.edn wonโ€™t do the trick then? (I did attempt to require a clojurescript version in there but it spit out a message saying it wouldnt use it)

thheller20:12:56

no that doesn't support git deps which you'll need for this I guess?

thheller21:12:14

yes it currently enforces a cljs version to ensure compatibility

ShaneLester21:12:54

Right, that makes sense. Alrighty. Does shadow generally follow releases of clojurescript pretty closely?

ShaneLester21:12:59

I could just wait for another release after all

thheller21:12:35

yeah I'll usually update within the day of release

ShaneLester21:12:52

Perfect. Iโ€™ll probably just wait for the next release then ๐Ÿ™‚

ShaneLester21:12:56

Thanks for your help!

flyboarder22:12:45

does this error ring any bells for anyone? java.lang.NoSuchFieldError: PARSE_RESULTS just after the server starts up

flyboarder22:12:08

I assume this is a dependency problem

thheller23:12:26

yes probably bad closure-compiler dependency