This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-16
Channels
- # announcements (8)
- # aws (28)
- # babashka (26)
- # beginners (125)
- # calva (18)
- # chlorine-clover (2)
- # cider (12)
- # cljs-dev (6)
- # cljsrn (4)
- # clojure (134)
- # clojure-europe (31)
- # clojure-italy (2)
- # clojure-nl (14)
- # clojure-uk (83)
- # clojurescript (81)
- # conjure (4)
- # cursive (2)
- # datomic (145)
- # emacs (13)
- # events (3)
- # figwheel-main (14)
- # fulcro (30)
- # graalvm (23)
- # graphql (15)
- # helix (21)
- # jackdaw (20)
- # juxt (1)
- # lambdaisland (4)
- # leiningen (2)
- # malli (12)
- # meander (22)
- # observability (22)
- # off-topic (27)
- # pedestal (3)
- # re-frame (12)
- # reitit (1)
- # releases (2)
- # rewrite-clj (3)
- # shadow-cljs (67)
- # spacemacs (7)
- # sql (1)
- # tools-deps (19)
- # unrepl (2)
- # xtdb (25)
[: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?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.
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?
npm allows that yes. can't remember the exact syntax though some like "the-dep":"github:foo/bar"
in your package.json
dependencies
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)
not interested in that at all. I think its a stupid concept thats easily fixed by better caching ...
yeah, I think it only really makes sense if you’re actually shipping ESM to prod w/o bundling
JS world is so obsessed with startup time ... which is something we'll never win in anyways so I don't care 😛
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 "uuid@^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.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
@cjsauer if the versions are incompatible then you are out of luck. I will not support having 2 versions of the same dep loaded.
Gotcha. I believe I can get around this using :js-package-dirs
option in this specific circumstance.
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.
I'll never give up :advanced
so I don't really care about turning cljs.core into a shareable ESM "library"
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
hm, what’s the correlation you’re making to defrecord
? and why would tuples be more akin to small vectors?
FWIW I’m talking about https://github.com/tc39/proposal-record-tuple
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
the big design goal seems to be to enforce the semantic #{a: 1, b: 2} === #{a: 1, b: 2}
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
yeah its really one of the least interesting TC39 proposals .. and most of them are already boring. nothing to get excited about at all.
WeakRefs is the only other one that I would find myself using probably immediately: https://github.com/tc39/proposal-weakrefs
and that’s only because I’m working on a side project that basically involves writing my own ref counter atm 😝
i’m writing my own reactive dataflow lib similar in API to reagent’s ratom/reaction API
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
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
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...
nevermind, I just restarted it and it updated the dependencies
right on 😃
@thheller Works great.