I'm getting a INTERNAL COMPILER ERROR trying to use https://github.com/oliver-moran/jimp in a new ClojureScript project. I've installed it with npm install --save jimp , and using :require ["jimp" :as jimp] . Not sure what to do, my Google searches have been dead ends.

Full, painful output:

I would check out what node_modules/jimp/browser/lib/jimp.js looks like

it might be in a weird format and/or require some sort of processing before being usable by shadow-cljs

I'll check it out, thank you for the pointer. It's a little frustrating to have this error from a "npm install" when it seems like a perfectly good CLJSJS package for jimp is available... but my understanding is that there's no way for me to use CLJSJS jimp in shadow-cljs, correct?

that’s correct, yeah. CLJSJS packages do not work with shadow-cljs

Have you seen the import style and checked what form it should be in the users guide?

you could try using the version that is on CLJSJS. It’s 0.2.27

@dpsutton the import style would probably not effect this, since it’s failing to even process the file

it’s not breaking on usage

Yikes, node_modules/jimp/browser/lib/jimp.js is big. I really don't know what I'm looking for here. Here's the file if you're curious.

yeah, it’s failing at the exports["default"] = void 0 for some reason

have you tried restarting shadow-cljs yet?

Yes, a couple times. Also updated it.

kk

you could also try and require something other than the browser build

e.g. ["jimp/es/index.js" :as jimp]

I’m just spit balling, I am not really sure why it fails to process that file

Good thinking. I'll try that and then the CLJSJS build if nothing works.

The only thing that came up in my searching was that "It's a Google Closure Compiler bug".

hmm it looks similar to https://github.com/google/closure-compiler/issues/1714

["jimp/es/index.js" :as jimp] worked! It compiles now.

How did you know to do that?

Also, do you think there's any point in raising this issue in the google/closure-compiler repo? Should I post the file there?

reading the docs and source of jimp helped a bit

the README talks about the different builds and their tradeoffs. the browser build is something specific to webpack

at least, AFAICT

either way, I had hope that the ES module was built in a way that was more amenable to GCC’s parser

Thanks for all your help with this, saved me hours.

@neil.hansen.31 is it not the coolest thing when somebody saves you mountains of effort?! gotta give thanks. gratefulness the blessing

I am trying to use shadow-cljs as a library. I want to grab some cljs with npm dependencies from a jar or files. I found out I can do that with get-classpath-entries and index-classpath from shadow.build.classpath . Furthermore I am using shadow.build.api to configure the build with the various api/with-* and seem to successfully compile-sources. But I don't see the output appear in the :output-dir I wonder what I'm missing for that to work.

you need to "flush" it but each :target option has its own way of doing that

okay, thanks. Searching for flush examples :)

what are you trying to do exactly? none of those things are documented in any way and not really part of any public API I recommend using 😛

On a high level, I am trying to make "plugins" that provide a nice way to use cljs and JavaScript libraries from Clojure by providing convenient api's to them and a base cljs app that relays usage of that api from clojure.

And right now I want to grab the base-app for each plug-in and compile it with shadow-cljs.

I don't understand 😛

for example if you'd want to use http://deck.gl

awesome webgl dataviz stuff

I'm wrapping that JS and allowing it to be used from Clojure

by running a web server with a base-app that understands calls you made to the clojure wraper

and the idea is to have multiple different JS libraries available like that

I still don't understand 😛

what is a "base-app"?

base app is some clojurescript that bridges the calls you made to the clojure wrapper to the actual JS

how do you call the actual JS?

I mean how do you intend to call CLJS from CLJ?

run a webserver that passes websockets messages to the running base-app

and the user is supposed to open a browser?

well, the library I'm making does that, but yes

ok, so its a regular :browser build and you just dynamically add a few :entries for your plugins?

Yes

so why the low level API use?

Hmm, I tried the higher level api, which is devtools.server I think? But that didn't pick up my resources well.

(shadow.cljs.devtools.api/compile* {:build-id :foo :target :browser :modules {:main {:entries [foo.bar-plugin] :init-fn {})

(shadow.cljs.devtools.server/start!) needs to be running before that though

then it would pick up :foo from a shadow-cljs.edn in project root right?

no, this is entirely custom config

you can call (api/get-build-config :foo) and then update-in or whatever and pass that to compile*

where would it get the resources from?

classpath

Okay, I'll give that api another go to see where I get. Thank you!

but I really don't have a clue what you are doing still 😛

I'm providing a nice way to use some JS libraries from CLJ basically

I don't understand what that means ... why would you ever use a JS library from CLJ?

because you want to visualize some data you have in clj

the http://deck.gl is webgl visualization. how do you use that from CLJ?

I guess the part I don't get is why you are trying to compile on the consumer side? that gets soooo complicated soo quickly

dealing with arbitrary npm install conflicts and so on

http://deck.gl uses layers, I generated macros that wrap them and visualize them

Sure it's another layer of indirection

I'm using first bootstrap, and now sci to compile functions in clj. It's complicated, but seems to work fairly well so far.

I guess I'm confused by the whole plugin thing which CLJS is completely terrible at

which is probably why you are compiling on the consumer side in the first place?

let me make a different suggestion maybe

sure

it sounds like you are writing the plugin anyways?

and you interact with that plugin over websocket provided by the base app

Yes

why not compile the "base-app" and provide that as part of the library (the compiled variant)

then on the consumer side you just need a webserver and serve static JS? no need to shadow-cljs to run at all?

if you want you can use :modules to split everything

yes, that's what I'm doing now, but I am combining multiple bundles which seems problematic

I never said compiled multiple bundles

that is a definite no-no.

I mean the base-app distribution contains compiled code for all plugins ...

yes I know that is less extensible

but plugins isn't something CLJS does well in any kind of way unfortunately

and giving up on all :optimizations is also terrible

Yeah I am aware of no optimizations and it being hacky

I dynamically resolve symbols from from the window, and the main blocker now is that react hooks don't seem to work if I include two plugins that use react.

my assumption is because there are multiple reacts required (eventhough same version)

that's why I was hoping that compiling it consumer side would solve those issues

yes combining multiple builds on the same page is a recipe for disaster

sidenote: I think it's interesting you wrote your own "cljs bootstrap" recently. I'm fairly happy with sci, but it is kind of restrictive, needing to include symbols, explicitly allowing certain usage of DOM stuff, and erroring when functions get called with variadic arguments.

I did no such thing 😛

well I guess kind of but it only looks like that

you mentioned something along those lines and maybe expanding upon it later, looking forward to reading more 🙂

sci works without a running shadow-cljs watch. my stuff doesn't 🙂

I'm mostly writing this as an extension of a clojure programmers toolkit in mind, not necessarily web-app proof.

So running shadow-cljs in the background and not doing advanced compilation is not an issue.

well but what happens if they already use shadow-cljs? two instances is not a great idea and its not designed to work that way.

@bbss > erroring when functions get called with variadic arguments that should not happen. btw, you can access most DOM stuff with {:classes {:allow :all 'js goog/global}} maybe

please post a bug report about the variadic stuff

Thanks @borkdude will give that a try. It was able to side-step the issue for now by declaring [.. & args] for the calls to not error.

@bbss Do you mean that sci errors on function calls that would also error on the JVM, but not in CLJS?

like: (apply inc [1 2 3])

Yes, I looked into the codebase for a while to try and fix it but didn't really figure it out at the time.

I don't see how one would like to turn that off honestly 😉

feel free to discuss any other sci issues in #babashka (sorry for the off topic-ness here)

Okay, bringing it there.

@thheller two instances wouldn't be good, agreed. Having all this plugin stuff play nicely with shadow-cljs is something I want to consider.

well I think you could create 2 new targets

one for the main app

and one for the plugins

but I don't even know how you'd deal with things using different versions

and how you handle plugins sharing dependencies and so on

so compiling on the consumer side may be your best option

alright, giving that a go. Thanks!

@thheller I just raised an issue for a possible race condition in shadow.cljs.bootstrap.browser/init for bootstrapped environments. Please ping me here or on GitHub if you need any further info or help as we have quite comprehensive tests. Thanks 🙂

@superstructor please setup a reproducible example if you want me to look into this

I'm getting an error in a production shadow-cljs build. It occurs only some of the time but I don't think that actually has to do with the issue. The error message is "ReferenceError: Highcharts is not defined". In Chrome I can click the line number in the error message to take be to the minimized JS. Chrome also has a handy formatter that will pretty print the minimized code (this feature is extremely cool btw. It even goes back and updates the line numbers in the error to point to the pretty printed code!) The line number it takes me to has this code:

d: Highcharts.SVGRenderer.prototype.symbols.arc(g, m, this.center[2] / 2, 0, {

I could add a top-level (set! (.-Highcharts js/window) highcharts) which may fix the issue but that doesn't seem like the right solution.

Highcharts is used in our app by including "highcharts": "8.1.2" in package.json and in a :require like this ["highcharts" :as highcharts].

I believe this is the exact error! https://github.com/highcharts/highcharts/issues/13710

Yep that was it. For those interested or who may hit this as well.. Rolling back to 8.1.0 appears to fix it 🙂

I’m trying to use an npm module that requires css. My understanding was that shadow just ignores css requires (according to this blog post https://code.thheller.com/blog/shadow-cljs/2018/06/15/why-not-webpack.html), but I’m getting this error:

Failed to inspect file
  /Users/tonykay/fulcrologic/ucv/node_modules/react-calendar/dist/Calendar.css

using 2.10.12 of shadow-cljs

rolling back to 2.8.100 (as a random choice) works

perhaps “works” is too strong a word. It doesn’t complain, but I guess it also ends up importing nothing. I think this lib just isn’t usable…nvm.

Hello @thheller! As part of my checklist to test out rewrite-cljc before release, I’m verifying against various projects. One of these projects uses Shadow CLJS. It taught me that rewrite-cljc does not currently compile under Shadow CLJS. Rewrite-cljc has an internal cljs version of potemkin import-vars which, by its nature, looks at analyzer data. I dug in and noticed that Shadow CLJS analyzer data is a wee bit different than ClojureScript analyzer data. The part that interests me is that Shadow CLJS includes macros only under :macros and ClojureScript includes them under both :defs and :macros. I don’t know if this is an intentional choice by Shadow CLJS, and I expect I can adapt, but thought I should letcha know. Here’s a repro of what I found: https://github.com/lread/repro-shadow-cljs-analyzer-macro-diff

And… I am by no means an expert here, so I may very well be doing something incorrectly or inappropriately!

@lee IMHO its a bug that CLJS includes macros from CLJS files. they can never be used and shouldn't exist in that ns as functions. leads to weird and strange behavior.

or maybe I'm misunderstanding something? basically shadow-cljs ignored defmacro in CLJS files. that is all.

Thanks for the reply @thheller! Ya, I really don’t know what is correct. My cljs import-vars only currently updates :defs and does not touch :macros and import-vars on macros works. I’ll experiment.

well your import-vars should likely ignore the macro defs since they are unusable anyways

no use in importing them to another ns, still useless there 😛

ah… interesting… thanks for the tip!

I've been wondering... with a "hot-reload" setup like shadow-cljs, is there any reason why I would ever want to "evaluate" my ClojureScript code through CIDER in Emacs? As in using cider-eval-defun-at-point after changing some code? My understanding is that shadow-cljs is just watching for changes to the saved file, and evaluating code in the CIDER REPL isn't so useful.

yeah I use the CLJS much less than CLJ because of hot-reload

I'm sure the answer will seem obvious... but as a newcomer I don't have a great conceptual model of how the whole system works. I don't really get the relationships between the ClojureScript that is getting compiled, evaluation in CIDER nREPL, shadow-cljs server, shadow-cljs watch app, etc.

@thheller could you elaborate on that? I don't understand.

read the user guide?

Sorry, I meant your last statement.

I realize that I have some studying to do to build my mental model.

in CLJ I use the REPL for basically everything all the time

in CLJS I barely ever use it

Got it, glad to hear I'm not missing something then.

Thanks for the tip, and for shadow-cljs. I wouldn't have made it this far in ClojureScript without it.

Hi, i'm trying to make a .js build for production.

But I get some funky errors on calls...

when on the server online

MBP:rolo-client janell$ npx shadow-cljs release frontend --debug
------------------------------------------------------------------------------
shadow-cljs - config: /Users/ja/nos.lv/rolo/rolo-client/shadow-cljs.edn
[:frontend] Compiling ...
Warning: Nashorn engine is planned to be removed from a future JDK release
------ WARNING #1 -  -----------------------------------------------------------
 Resource: com/cognitect/transit.js:649:8
 variable module is undeclared
------------------------------------

thats not an error thats a warning. you can ignore that one

okay cool

in the clientside when i run it i get some red... pardon the redness

kinda hard to diagnose but i'm on it ^.^

https://shadow-cljs.github.io/docs/UsersGuide.html#infer-externs

make sure thats on :auto

learning in progress pls wait

no dice yet but i'll keep learning about the options

gonna try with optimizations simple

😄 😄 😄 😄 😄 😄 😄

we are live ladies and gentlemen

@thheller thanks again for your help on the analyzer differences. I dug a little more. My problem arose from the fact that Shadow CLJS and ClojureScript return different data for resolve. Details are here if you are curious: https://github.com/lread/repro-shadow-cljs-analyzer-macro-diff#resolve-macro-differences