I seem to have lost my hotreload when hacking on calva-lib. I have tried some older versions of VS Code, but it is the same. Also some older versions of shadow-cljs, but same… I need some tips on how I can track this down. Totally horrible to be back in compile->restart land.

https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html

you have a console for wherever calva-lib is running in right?

Yeah. It does have some strange cache-related error messages… Let me check…

Hmmm, no. Got rid of those messages, but still no hot-reload for me.

what does the console say?

oh and you are using :node-library so the hot-reload doesn't work for exported vars?

Right now it says nothing.

I have had hot-reload working…

Yes, that was it! My exported vars are usually very thin dispatchers so not really tried if hot reload works for them. It works for non-exported stuff.

Then I am good, Just need to thin this one down. 😃 Curious about why it doesn’t work for those vars though.

actually I can make that work. just never updated the initial "naive" implementation 😛

Cool. I can write my stuff explicitly with exported dispatch-only api, but would of course be nicer not to have to do it for that reason.

Any chance I can some day get a non-flat export for my :node-library?

the reason it doesn't work right now is that basically in JS it is doing var something = require(".../calva-lib.js")

I see. Makes sense.

so something will be the {whatever: some-function)

and we can't update something

but I can make it work by using getters for the actual object in development

so we can switch what it actually accesses later

or just hold onto the exported object and update that

I’m good with just knowing what was going on, but if that is not tons of work for you, it is on my wishlist. 😃

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

Have you written about the differences between npm-library and node-library are somewhere? I mean conceptually, but yeah, faturewise too.

you mean :npm-module?

ClojureScript is my first real contact with node land, so obvious things are not so obvious to me.

Yeah, I meant that. Haha.

:npm-module basically tries to expose the CLJS namespaces to JS

:node-library lets you collaps namespaces down to one single object

:node-library should be preferred in almost all cases (output is more efficient/compact)

The single object is flat though. Which a while had me try with :npm-module.

Never got the entry point to work with that though.

yeah if you basically just want to use the CLJS namespaces directly in JS then :npm-module is the way but it has other issues that makes it more complicated to work with

ie. hot-reload and REPL

I love my :node-library. Will stay with it. Hopefully grow it a bit faster so that you start liking Calva more. 😃

hehe

you are brave for still being able to work in typescript 😛

It is actually pretty sweet how when in cljs I can reach both the node and the clojure ecosystems.

I want to throw my PC out the window every time I even look at TS code 😛

I worry for your office when you have to look at JS code then…

Actually it is not so much that I want it. It has been pragmatic, but also will become problematic. So will start a “background thread” bringing stuff over piece by piece.

just a big PC graveyard in my garden 😉

I have to admit I kinda like TypeScript a bit too. Mainly for its improvement over JS, but also it is quite nice with the IDE support you are rewarded with when you write types for things.

yeah I have to admit that part is pretty nice

But Calva just got signature help rivaling that of TypeScript’s. So there is that approach as well. 😃

is it easy to get a workflow where I can get a clj and cljs repl simultaneously running for a project using emacs/cider?

(also using deps.edn)

cider-jack-in-clj&cljs

wow, thanks!

is it possible to configure shadow-cljs.edn to match this call: (shadow.cljs.devtools.api/watch :app {:autobuild false}) when running shadow-cljs watch app?

have tried setting :autobuild false in various places in shadow-cljs.edn but haven't been able to figure it out

there is not. feel free to open an issue though.

okay!

Why do people like Typescript by the way?

I’ve got a super minimal example where my cljs ‘requires’ an adjacent .js file which requires an npm module, lodash. After compiling, and when I try to run it, I get Module not provided: shadow.js.shim.module$lodash. That file, shadow.js.shim.module$lodash.js is in my cljs-runtime dir.

My config file

@thheller any ideas what I’m doing wrong?

@gdwarner do you have the actual code too?

I'm assuming you have (:require ["./some.js" :as x]) and in that JS const x = require("lodash");?

that’s basically it

I need to know if thats exactly it though 😛

JS deps requiring NPM deps is in kind of a rough spot right now because the closure compiler changed something

so it may work if you switch it to use import X from "lodash"

if you have something reproducible that would help

There’s a lot of cruft in there from testing various things. Let me slim it down…

I think I was relying on a bug in the closure compiler which they fixed

so I kinda need to come up with a new strategy for this

hmm…

Slightly slimmer…

but try it with ESM notation. so import/export. no require

commonjs support is likely going away

haven't touched the JS support in a while. don't really recommend using it 🙂

ESM notation is working well for us atm

runtime is nodejs 12, which doesn’t support ESM notation. 😞

doesn't matter. is is transpiled as part of the CLJS compilation

Ok. Another bane of my existence that I want to pick your brain about. We’ve got a javascript code base. We’d like to write new functionality in cljs. Our unit tests are using jest. Jest and the closure compiler don’t seem to like each other. goog is not defined. Do you know anything about this? I imagine getting to the bottom would require in-depth knowledge in either jest or closure or both.

don't know anything about jest sorry

if the :node-library code isn't loaded properly then it may do some kind of processing that breaks the already brittle output 😛

From what I’ve been able to figure out, jest messes with node’s require function. The other testing framework I tried, mocha, doesn’t have the same problem. But, its also interesting that jest seems to work fine with every other node library. I wonder if its related to closure’s heavy use of globals.

just to report back: ESM-style worked

Huh… re the ‘jest’ problems I was having: I only have issues with development builds of the cljs. Release builds work fine. :thumbsup:

What is the default optimizations for a :node-library target?

:advanced