This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-21
Channels
- # announcements (3)
- # babashka (98)
- # beginners (69)
- # chlorine-clover (6)
- # cider (24)
- # cljsrn (2)
- # clojure (97)
- # clojure-australia (2)
- # clojure-berlin (6)
- # clojure-dev (57)
- # clojure-dusseldorf (4)
- # clojure-europe (19)
- # clojure-italy (5)
- # clojure-nl (10)
- # clojure-seattle (1)
- # clojure-uk (44)
- # clojuredesign-podcast (13)
- # clojurescript (45)
- # cursive (4)
- # data-science (1)
- # datomic (32)
- # emacs (7)
- # events (5)
- # fulcro (17)
- # java (12)
- # jobs (1)
- # lumo (2)
- # malli (5)
- # observability (16)
- # off-topic (1)
- # pathom (3)
- # pedestal (4)
- # rdf (14)
- # re-frame (54)
- # reagent (4)
- # releases (3)
- # remote-jobs (1)
- # reveal (55)
- # shadow-cljs (34)
- # spacemacs (14)
- # specter (9)
- # tools-deps (16)
- # xtdb (7)
Hi, anybody else experienced a hanging compilation with :advanced mode, when :target :bundle is used? I canโt for the heck of me figure out why this happens to my project. I have a development/figwheel-main setup that does work with :target :bundle, ie. it will properly use my external libraries, but :advanced compilation seems to hang
Sounds like something I hit. Some notes on this question about workarounds... https://ask.clojure.org/index.php/9602/recommended-webpack-config-for-clojurescript-bundle-target
{:main myns.core
:output-to "target/index.js"
:output-dir "target"
:optimizations :advanced
:target :bundle
:verbose true
:bundle-cmd {:none ["npx" "webpack" "./target/index.js" "-o" "./target/" "--mode=development"]
:default ["npx" "webpack" "./target/index.js" "-o" "./target/"]}
:closure-defines {cljs.core/*global* "window"}} ;; needed for :advanced compilation
but it never gets to the point of bundling, just hangs at:
Applying optimizations :advanced to 281 sources
no clue about the :bundle-cmd
side of things but :advanced
can take a long time. depends on your code. I've seen anything between a couple sec and a few minutes
@kah0ona if you're on linux, you could try using strace
to see if it's hang/waiting for something, or if it's just doing bunch of work. Try strace <your command>
and see if you get tons of output (busy working) or if it stops outputting logs after a while (stuck waiting for something)
Using juxt/tick
in cljs to do some lightweight formatting (just want to show how long time ago something happened) but tick pulls in js-joda which ends up being 30% of my bundle size. Anyone got any handy library/snippet for cljs for taking a js/Date and turning it "X seconds/minutes/hours ago" that is a bit easier on the size side?
does this work for you? https://github.com/luciodale/arco
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat can do quite a bit.
thanks to both for the pointers. Yeah, DateTimeFormat is nice, but don't think it does "durations" that would be needed to get the "X minutes ago", or at least I don't see how I could get that from DateTimeFormat
If you're OK with JS interop: https://github.com/iamkun/dayjs
dayjs(1536484369695).fromNow();
// => "5 days ago"
Not sure if it has better precision than days.yeah, js interop is fine, as long as the library is small and nimble, and don't end up to big in the bundle. I'll take a look at dayjs, thanks
I've glanced at a few articles that talk about replacements for moment
- day.js
seems to be the most lightweight.
in the end, what ends up taking lots of space is the locales, rather than the libraries themselves
yeah, tried bundlephobia before but not sure what they use to do the calculations, don't think it's accurate with closure compiler, as it's hard to know before including it and using it how much space it'll actually take
Indeed. But I think it can be useful when comparing different JS libraries between each other.
actually I was thinking of this before https://github.com/tc39/proposal-intl-duration-format ... still a work in progress unfortunately
ah sweet, haven't seen that before. Thanks @U051B9FU1
I can't believe no one has suggested this but if "X seconds/minutes/hours ago" is all you really need just write that function yourself. its trivial and smaller than any lib you'll find. pretty sure there is also something in the closure library for this.
https://github.com/google/closure-library/blob/master/closure/goog/date/relative.js#L8-L9
Good to know that Closure has such functionality. Regarding writing it yourself - it's not that easy if you need l10n.
well yes that makes everything harder. I think the closure lib variant handles that.
@U05224H0W yeah, was looking for snippets as well! Don't want to spend any time re-writing something that's already been written, the code from relative.js looks good enough so thanks for linking that! :thumbsup:
makes note to self that I should really sit down and at least scan the top-level API for the closure-library, I always tend to forget/miss the built-in functionality
I have a local checkout and typically just "find in files" and pretty often there is something ๐
I'm running frontend tests on nodejs and since nodejs is missing some browser things, I need to create stubs like (set! (.-document js/global) (clj->js {:getElementsByClassName (fn [_] [])}))
. I'm wondering if there's already a comprehensive set of stubs in a repo somewhere.
I have a customer getting errors where the data format looks weird: The logs says :fxrate #object[h {:value 1.1823}]
but I would expect :fxrate 1.1823
where is this format coming from? Any ideas or leads appreciated.
Hard to say anything specific without my crystal ball. :)
But #object[...]
can appear when you try to print a JS object that's not a plain object (i.e. for which object?
returns false).
And the h
part may easily come from some minified class name.