Fork me on GitHub
#shadow-cljs
<
2020-06-16
>
plexus14:06:26

[:main] Build failure:
babel failed?
{:file "/home/arne/clj-projects/xterm-sci/node_modules/local-echo/lib/HistoryController.js"}
ExceptionInfo: babel failed?
is there an easy way to see the output from babel?

thheller14:06:45

the server process should be logging more?

thheller14:06:55

hmm or maybe not. this isn't supposed to fail. maybe try restarting.

plexus15:06:46

no, restart didn't help...

plexus15:06:56

ooooh I know what it is... starting shadow from cider which is started from emacs which doesn't have node on its PATH. In the shell I use nvm but emacs doesn't see that.

plexus15:06:18

figured it out by looking at the nrepl-server buffer

plexus15:06:12

but... turns out I actually need some changes that aren't released to npm yet. Is there any way to consume npm/js libs off github directly?

thheller15:06:49

npm allows that yes. can't remember the exact syntax though some like "the-dep":"github:foo/bar" in your package.json dependencies

thheller15:06:25

npm also takes local dirs. plenty of stuff you can do.

plexus15:06:37

thanks for the pointers, I'll check that out

plexus15:06:46

(no pun intended :P)

thheller21:06:08

teaser time 😉

(ns demo.esm.a
  (:require
    ["" :refer (copy)]))

🤯 15
thheller21:06:31

(ns demo.esm.a
  (:require ["" :as x]))

🎉 3
thheller21:06:37

who needs npm anyways 😉

lilactown21:06:57

is shadow going to emit native ESM?

thheller21:06:21

in release yes, in development not really. 😛

lilactown21:06:37

today I was thinking about how CLJS could be used similar to the latest fashion of JS dev tooling that compile .js/.ts files on demand by a dev server, in combination with native ESM (so you don’t need to bundle)

lilactown21:06:30

it would be terrible for DCE (maybe) but interesting in dev mode

thheller21:06:37

not interested in that at all. I think its a stupid concept thats easily fixed by better caching ...

lilactown21:06:21

yeah, I think it only really makes sense if you’re actually shipping ESM to prod w/o bundling

thheller21:06:38

JS world is so obsessed with startup time ... which is something we'll never win in anyways so I don't care 😛

cjsauer21:06:45

When running shadow-cljs release I’m seeing the following warnings:

npm package "util" expected version "[email protected]" but "2.0.4" is installed.
npm package "@cucumber/messages" expected version "[email protected]^7.0.3" but "3.4.0" is installed.
I did a bit of searching and found this github issue: https://github.com/thheller/shadow-cljs/issues/547 with the quote: > It is quite intentional that it does not follow standard node resolve rules since I will never allow having multiple versions of the same dependency in one build (which happens regularly in webpack builds with nested node_modules dirs). I understand the rationale, but I’m not clear on how I would go about resolving conflicts like the one above, which seem like they’d be rather common. I could use :js-package-dirs to force the search path to include the newer version of uuid for example, but then the warnings would just swap to another conflict saying that uuid was too new.

lilactown21:06:59

well if we were willing to chop up cljs.core more… maybe we could get there 😛

lilactown21:06:07

if records + tuples make it past TC39 in a reasonable state, there might be an opportunity to move our bespoke data structures to a lib and use native immutable data in core

thheller21:06:09

@cjsauer if the versions are incompatible then you are out of luck. I will not support having 2 versions of the same dep loaded.

cjsauer21:06:48

Gotcha. I believe I can get around this using :js-package-dirs option in this specific circumstance.

thheller21:06:51

no you really can't 😛

cjsauer22:06:08

Yea you’re right, :js-package-dirs is not what I need. In my specific circumstance i have a big monolith project. I can split the monolith in a way that would avoid these conflicts altogether.

thheller21:06:58

records and tuples to absolutely nothing for the data structures we use?

thheller21:06:51

I'll never give up :advanced so I don't really care about turning cljs.core into a shareable ESM "library"

lilactown21:06:56

like I said, if they made it out of TC39 in a reasonable state 😛 records are almost enough like maps, and tuples almost enough like vectors, that it makes me want to use them as replacements

thheller21:06:00

they aren't even remotely close to comparable

thheller21:06:35

records compare to defrecord maybe but not to maps

thheller21:06:05

tuples for small vectors maybe, not with many members

lilactown21:06:47

hm, what’s the correlation you’re making to defrecord? and why would tuples be more akin to small vectors?

lilactown21:06:28

the proposal is pretty different from any of the immutable data that CLJS has anyway, and they seem dismissive of ideas that would make them more general purpose

thheller21:06:05

granted I know nothing about how they are planning to implement it

thheller21:06:16

but I doubt very much they are going with the HAMT route clojure uses

thheller21:06:39

so records just look like syntax sugar over object/arrays

thheller21:06:42

just like tuples

thheller21:06:51

like any other language with those concepts

thheller21:06:14

so records aren't anything like generic maps

lilactown21:06:39

yeah I imagine it will vary by the implementation

thheller21:06:36

> Non-string keys are coerced to strings.

rage4 3
thheller21:06:46

so absolutely not even remotely close to clojure maps ...

lilactown21:06:58

the big design goal seems to be to enforce the semantic #{a: 1, b: 2} === #{a: 1, b: 2}

thheller21:06:01

still probably can't use them as keys in Map in Set though

lilactown21:06:03

which, there are many ways of doing that. the solution they’ve chosen is to restrict what can be used as keys and values very tightly to make it easy at the VM level to do that

lilactown21:06:36

I think you can use them as keys in Map and Set , but you can’t do the reverse!

thheller21:06:35

yeah its really one of the least interesting TC39 proposals .. and most of them are already boring. nothing to get excited about at all.

isak21:06:31

I heard there was a multi-threading thing - was that rejected?

lilactown21:06:54

WeakRefs is the only other one that I would find myself using probably immediately: https://github.com/tc39/proposal-weakrefs

lilactown21:06:27

and that’s only because I’m working on a side project that basically involves writing my own ref counter atm 😝

dpsutton21:06:48

what prompted your need for a ref counter?

lilactown21:06:33

i’m writing my own reactive dataflow lib similar in API to reagent’s ratom/reaction API

lilactown21:06:40

just for fun

lilactown22:06:17

you have to keep a reference to any upstream or downstream dependencies in each node to know when to fire, and when to clean up

lilactown22:06:18

weakrefs would basically be an addon to that where I could add a finalizer which detects if a watched node falls out of scope and gets GCd, then I can use that to cleanup any connected nodes that aren’t being listened to anymore

sova-soars-the-sora22:06:04

Hi, how can I get shadow-cljs to install clojurescript dependencies? I added them to the :dependencies vector in the shadow-cljs.edn file, but it reports unavailable...

thheller22:06:46

"reports unavailable" - what does that mean?

sova-soars-the-sora22:06:12

nevermind, I just restarted it and it updated the dependencies

thheller22:06:27

ah yes, changing :dependencies or :source-paths requires restarting