Fork me on GitHub
#shadow-cljs
<
2019-11-08
>
pez10:11:07

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.

thheller10:11:23

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

pez10:11:23

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

pez10:11:56

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

thheller11:11:09

what does the console say?

thheller11:11:21

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

pez11:11:34

Right now it says nothing.

pez11:11:19

I have had hot-reload working…

pez11:11:40

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.

pez11:11:30

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

thheller11:11:42

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

pez11:11:09

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.

pez11:11:42

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

thheller11:11:08

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

pez11:11:23

I see. Makes sense.

thheller11:11:28

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

thheller11:11:39

and we can't update something

thheller11:11:58

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

thheller11:11:15

so we can switch what it actually accesses later

thheller11:11:39

or just hold onto the exported object and update that

pez11:11:42

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. 😃

pez11:11:13

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

thheller11:11:01

you mean :npm-module?

pez11:11:04

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

pez11:11:13

Yeah, I meant that. Haha.

thheller11:11:31

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

thheller11:11:44

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

thheller11:11:02

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

pez11:11:03

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

pez11:11:33

Never got the entry point to work with that though.

thheller11:11:45

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

thheller11:11:48

ie. hot-reload and REPL

pez11:11:54

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

thheller11:11:19

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

pez11:11:26

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

thheller11:11:11

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

😂 4
sheepy 4
4
Stefan11:11:42

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

pez11:11:58

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.

thheller11:11:10

just a big PC graveyard in my garden 😉

16
papachan11:11:48

picture pleaaaase!

pez11:11:34

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.

thheller11:11:42

yeah I have to admit that part is pretty nice

pez11:11:09

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

jjttjj13:11:15

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

jjttjj13:11:00

(also using deps.edn)

dpsutton13:11:34

cider-jack-in-clj&cljs

jjttjj13:11:31

wow, thanks!

Saikyun14:11:07

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?

Saikyun14:11:27

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

thheller14:11:14

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

David Pham14:11:34

Why do people like Typescript by the way?

gdubs15:11:46

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.

gdubs15:11:09

My config file

gdubs15:11:56

@thheller any ideas what I’m doing wrong?

thheller16:11:22

@gdwarner do you have the actual code too?

thheller16:11:05

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

gdubs16:11:51

that’s basically it

thheller17:11:28

I need to know if thats exactly it though 😛

thheller17:11:03

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

thheller17:11:24

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

thheller17:11:36

if you have something reproducible that would help

gdubs17:11:21

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

thheller17:11:05

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

thheller17:11:24

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

gdubs17:11:45

Slightly slimmer…

thheller17:11:49

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

thheller17:11:58

commonjs support is likely going away

thheller17:11:53

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

lilactown17:11:19

ESM notation is working well for us atm

👍 4
gdubs17:11:19

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

thheller17:11:36

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

gdubs17:11:18

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.

thheller17:11:43

don't know anything about jest sorry

thheller17:11:28

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

gdubs17:11:17

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.

gdubs17:11:59

just to report back: ESM-style worked

gdubs18:11:04

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

pez20:11:50

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

thheller20:11:46

:advanced

metal 4