This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-03
Channels
- # announcements (1)
- # babashka (2)
- # beginners (17)
- # calva (11)
- # cider (4)
- # clara (3)
- # clj-kondo (19)
- # cljs-dev (60)
- # clojure (27)
- # clojure-europe (1)
- # clojure-nl (2)
- # clojure-spec (1)
- # clojure-uk (11)
- # clojurescript (128)
- # core-logic (7)
- # cursive (7)
- # data-science (3)
- # datomic (76)
- # defnpodcast (4)
- # fulcro (5)
- # malli (5)
- # off-topic (7)
- # re-frame (1)
- # reitit (3)
- # shadow-cljs (86)
- # spacemacs (5)
- # test-check (48)
- # tools-deps (9)
- # vim (12)
- # xtdb (6)
With respect to a potential release: Canary is all at green. ✅ https://github.com/cljs-oss/canary
@thheller I agree that /
should always work w/ an alias but that's not really different from today
if we just make :as
directly usable for anything but CLJS namespaces most edge cases become simpler
but the argument against :as
is the ambiguity. (:require [some.thing :as x])
x/foo
and x.foo
end up with the same code but are treated differently by the analyzer
there were a bunch of problems when you don't know whether something is or isn't a namespace
I'm fine with (:import [some.thing Foo])
and (Foo/staticFn)
but :refer (Foo)
(Foo/staticFn)
feels rather icky
and there is no ambiguity in the :import case, so that would be a no-brainer to re-implement?
I guess we could add that for a nnext release and ponder about the other :refer issue some more (or not)
why is this supported in CLJS (and diverging from Clojure), is there a real need for it?
(set! (js-obj "a" 1) -a 2)
to be honest I've never seen it used in the wild, but probably because not a lot of people know this exists?
oh: https://github.com/clojure/clojurescript/commit/8b37ace4ae7d780515ad1255b64597e50adc7507
I've just fixed linting this set! variant in clj-kondo, but re-linting CLJS itself doesn't seem to have an effect on the amount of false positives. Maybe it's not used anywhere?
Would an issue like https://github.com/bhauman/figwheel-repl/issues/10 be something that the latest CLJS release’s lib analysis tool would uncover?
@tkjone on a plane so I can't the see link for some reason - but is the issue that Figwheel has a typo?
Yes. Figwheel is referencing glog/warn
as opposed to glog/warning
.
What was interesting is that I only got the warn when using latest CLJS
I haven’t sorted out the root cause, but unit tests failed on Windows: https://clojure.atlassian.net/browse/CLJS-3178