Fork me on GitHub
#shadow-cljs
<
2019-01-09
>
Mark Addleman00:01:29

I'm trying to use antizer library in clojurescript (https://priornix.github.io/antizer ) . When I run my build, I get The required namespace "cljsjs.antd" is not available, it was required by "brickmarket/ui.cljs". My deps.edn includes

cljsjs/antd               {:mvn/version "3.12.0-0"}
           antizer                   {:mvn/version "0.3.1"}
any guess what i'm doing wrong?

Mark Addleman00:01:10

i've tried running npm install cljsjs/antd but npm fails to install it.

lilactown05:01:13

so you don’t need to include cljsjs/antd in your deps.edn

lilactown05:01:27

you will need to install antd via npm: npm install --save antd

lilactown05:01:33

once you’ve done that, you’ll need to create your own cljsjs.antd namespace that exposes antd. See https://shadow-cljs.github.io/docs/UsersGuide.html#cljsjs

mavbozo06:01:55

i always get this message in chrome console shadow-cljs: reloading code but no :after-load hooks are configured!

mavbozo06:01:18

although I have put :devtools {:before-load cljs.dev/stop :after-load cljs.dev/start} in my :builds profile

thheller09:01:54

do not use namespaces starting with cljs.. they are reserved for CLJS itself. the hooks are not allowed in cljs.*

mavbozo09:01:53

thank you for the information

romdoq08:01:39

I'm seeing intermittent issues when building a release, where it will fail with the error:

IllegalStateException: could not find where to put constant for module goog.labs.useragent.engine.js
        shadow.build.closure.ReplaceCLJSConstants.process (ReplaceCLJSConstants.java:60)
        ...
Any suggestions for what kind of thing should I be looking for to track down what might be triggering this?

romdoq09:01:02

it seems to have started occurring in a commit where I split some code out into its own file, with no other changes 😕

thheller09:01:21

@mel.collins that is odd? do you have :depends-on configured correctly?

romdoq09:01:22

we're just using a single module at the moment, so we don't have any :depends-on configured

thheller09:01:10

> I split some code out into its own file

thheller09:01:13

what does that mean then?

thheller09:01:25

just an extra ns?

romdoq09:01:03

yeah, I had an oversized myapp.views.main, and split out a bunch of the views into their own namespace

thheller09:01:47

that is odd. what is your build config then?

thheller09:01:25

IllegalStateException: could not find where to put constant for module this should only happen when :modules are setup incorrectly. can't explain how it would happen otherwise.

thheller09:01:48

do you have the correct closure-compiler version? yes if using shadow-cljs.end, maybe not if using deps/lein

romdoq09:01:54

hmm, if I remove the .shadow-cljs cache dir the build works once, but then fails on subsequent attempts

romdoq09:01:21

we're not using deps or lein at this point

thheller09:01:24

that is even weirder. do you do any kind of macro trickery?

thheller09:01:38

(side-effecting macros)

romdoq09:01:49

:modules {:main {:entries [myapp.core]}}

romdoq09:01:02

I don't think there's any macro trickery

romdoq09:01:46

not that we've written anyway. I'm not sure about deps, but the deps didn't change when it started to break

thheller09:01:16

so when it starts breaking

thheller09:01:19

hmm I have no idea how it would even be confused about goog.labs.useragent.engine.js

thheller09:01:33

there are no CLJS constants in that file

thheller09:01:43

so the only time I ever saw this error was with badly defined :modules.

thheller09:01:50

you are using :target :browser I assume?

thheller09:01:26

it doesn't make sense that is only work once as the input to the compiler will be identical to the first one when caching is used

romdoq09:01:43

This is :target :npm-module and :runtime :browser

thheller09:01:17

oh. I guess I need to filter :modules. it is not allowed for :npm-module builds

thheller09:01:25

just use :entries.

thheller09:01:43

:build {:stuff {:target :npm-module :entries [myapp.core]}}

romdoq09:01:21

oh interesting, I did not realise

thheller09:01:09

:npm-module desugars to a pretty complex :modules configuration

thheller09:01:21

you just basically added one module it didn't expect so it falls over

romdoq09:01:09

hah, well it took its time falling over, since the config has been like that for months! Something about a camel's back 😄

thheller09:01:42

yeah still no idea why it would compile once at all

romdoq09:01:44

Yeah, that's fixed that IllegalStateException, thanks.

romdoq09:01:52

but we've another branch with the same happening for goog.dom.dom.js, even after with the :entries fix

romdoq09:01:14

that branch switched to using deps.edn though, which you mentioned something about?

thheller09:01:59

it is unlikely that this is related to bad dependencies

thheller09:01:14

just make sure to remove :modules from all :npm-module builds

thheller09:01:22

I'll validate and ensure that in the future

romdoq09:01:42

yeah, I just checked out a commit prior to the deps.edn change, and it's still complaining about goog.dom.dom.js. But this is after :modules has been removed!

thheller09:01:19

same error?

romdoq09:01:00

the heck? This branch is complaining about goog.labs.useragent.engine.js again. Same IllegalStateException, yeah.

romdoq09:01:51

could ^:private be a problem?

thheller09:01:08

This branch. are you sure this branch has the updated build config? if you have a server instance running it may still be using an older version too?

romdoq09:01:16

yeah, I rebased on the updated config, and triple-checked that it was the right shadow-cljs.edn. No server instance running either.

romdoq10:01:56

huh, the first time I build I get IllegalStateException: could not find where to put constant for module goog.dom.dom.js, but subsequent times I get the same error but for goog.labs.useragent.engine.js again.

thheller10:01:11

I'm not sure what is happening. I've never seen that error in :npm-module builds before.

thheller10:01:57

if you can please send me the contents of the .shadow-cljs/builds/<your-build>/release directory. its all the cache files and generated JS. maybe I can find something?

thheller10:01:41

and the full build config? maybe there is some other option messing with things

romdoq10:01:33

I'm still investigating right now, but I'll zip and send you some stuff after lunch if I don't find anything

thheller10:01:09

make sure you are on the correct directory on the correct machine. wouldn't be the first time that someone was debugging something locally but actually executing something via an ssh connection on a totally different machine 😉

romdoq10:01:36

hah yeah, that's always a good one. Sadly not the case in this instance!

romdoq12:01:43

okay, so this was unexpected. It seems the mere presence of an :options keyword in any view function is the trigger, even if the function isn't used.

romdoq12:01:07

I can use :options in re-frame subs or cljss/defstyles wihtout issue

thheller12:01:23

the keyword is unlikely to be the issue

thheller12:01:51

or rather it is more likely that its the issue WHEN it is used or how

thheller12:01:55

not the keyword itself

romdoq12:01:24

lol, now that I've said that I can't get it to break again

thheller12:01:27

cljss does some fairly bad macro stuff. so maybe thats it

romdoq12:01:20

right now

(defn secondary-config-mappings
  []
  {:options nil})
triggers the error, but
defn secondary-config-mappings
  []
  {:optionss nil})
does not. The function is not used anywhere in the code.

thheller12:01:15

hmm I have an idea

thheller12:01:38

hmm no. not really

romdoq12:01:04

huh. If I put (def blah :options) in another file, the error doesn't trigger

romdoq12:01:29

but if it's in the same file as the above defn, the error still triggers

romdoq12:01:44

@thheller do you still want a copy of the failing build files?

romdoq12:01:06

apparently it's not just keywords, but any variable called options triggers it too 😕

romdoq12:01:10

on second thought, that might be also related to keywords, since the only occurrences in this code was from deconstructing maps

romdoq12:01:31

yeah, a basic function with an options argument didn't trigger the error

thheller13:01:25

@mel.collins yeah the files would help. I cannot reproduce this in any way. build config would also help just in case there is something misconfigured

ShaneLester15:01:48

Does shadow not detect changes to macros for live-reload / compile purposes? Or do we have something configured incorrectly? Just saw a case where we made a change to a macro, saved, nothing kicked off by shadow, changed a line outside of macro and saved, and it behaved normally.

thheller15:01:41

it should support live-reload for macros yes

ShaneLester15:01:59

Hmmm okay. That at least gives us the “Okay something is wrong there” flag. haha. Thanks

thheller15:01:23

totally possible that its not entirely accurate since macros are a bit tricky

ShaneLester15:01:29

Right… I need to read about them a bit more to understand, I think.

ShaneLester16:01:40

Would it change anything that it’s a macro from a library? a Spec macro in this case.

ShaneLester16:01:06

And we only changed how we called it, not the macro itself, I was mistaken before

cjsauer17:01:06

What is the recommended strategy for developing locally on both client (browser) and server code with shadow? Does it make sense to have two completely separate clj projects? Should I spin up my server project's REPL, start the system, etc....and then configure my client project's :proxy-url to point at the local server? Or maybe it's more appropriate to configure the client's :http-handler to reference the server's main handler fn? This would suggest that the client/server projects are one monolith, or that the client project depends on the server project somehow. Just trying to get a feel for what others have been doing...

wilkerlucio17:01:41

I would separated a few source folders, start with shared, server, client, so most of the code goes in shared, and in the others only specific code that calls to specific host features (like node FS or browser fetch, etc...)

wilkerlucio17:01:53

then in a single project, have one build for each case (client/server)

cjsauer17:01:35

That makes sense, and should be pretty straightforward with tools.deps and :local/root. What about "integration" between client/server though? I think what I'm confused about is how do I replace the shadow development server with my own server? Is the :http-handler setting the preferred approach?

wilkerlucio19:01:04

those don't collide with each other, the shadow http is for pure cljs cases, what you gonna do is implement you own on the Node side (using express or whatever), then you run your server separated, maybe there is a way to hook on the shadow one, but I believe that would give you more headaches to deploy

thheller18:01:40

@cjsauer I just put all the code in one repo and have multiple builds. easiest to share code that way

cjsauer19:01:53

@thheller @wilkerlucio thank you, I think I've got it working now :thumbsup: