Fork me on GitHub
#cljs-dev
<
2019-11-03
>
mfikes14:11:09

With respect to a potential release: Canary is all at green. https://github.com/cljs-oss/canary

💚 4
dnolen15:11:07

@thheller I agree that / should always work w/ an alias but that's not really different from today

thheller15:11:27

(ns foo.bar
  (:require
    [goog.string.format]
    [goog.string :refer (format)]))

dnolen15:11:33

(require [goog.date.UtcDateTime :as utc]) already works unless I missing something

thheller15:11:44

this is one of the tricky cases

thheller15:11:01

you can't leave out the goog.string.format require since then format won't exist

thheller15:11:13

but the only way to alias format is using the goog.string

dnolen15:11:43

right I'm not sure I'm interested in that case just now

thheller15:11:46

so the same case for classes

thheller15:11:21

(ns foo.bar
  (:require
    [goog.foo.SomeClass]
    [goog.foo :refer (SomeClass)]))

thheller15:11:34

if SomeClass is actually defined in the same file then no second require is needed

thheller15:11:42

sometimes they are. sometimes they are not

dnolen15:11:43

right but you don't know

thheller15:11:56

so :refer (SomeClass) (SomeClass/staticFn ...) seems problematic to me

thheller15:11:58

also doesnt' work for any JS deps if we make it dependent on @constructor

thheller15:11:19

if we just make :as directly usable for anything but CLJS namespaces most edge cases become simpler

thheller15:11:16

(and we already do for JS deps, just need to extend it to Closure namespaces)

thheller15:11:58

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

thheller15:11:19

but the . handling has many other issues already so probably doesn't matter much

dnolen15:11:43

right but like I said it used to work this way

dnolen15:11:11

there were a bunch of problems when you don't know whether something is or isn't a namespace

dnolen15:11:21

to be honest we fixed this so long ago I don't remember all the cases anymore

thheller15:11:48

I'm fine with (:import [some.thing Foo]) and (Foo/staticFn) but :refer (Foo) (Foo/staticFn) feels rather icky

borkdude15:11:35

and there is no ambiguity in the :import case, so that would be a no-brainer to re-implement?

borkdude15:11:53

I guess we could add that for a nnext release and ponder about the other :refer issue some more (or not)

borkdude15:11:14

why is this supported in CLJS (and diverging from Clojure), is there a real need for it?

(set! (js-obj "a" 1) -a 2)

borkdude16:11:00

to be honest I've never seen it used in the wild, but probably because not a lot of people know this exists?

thheller16:11:12

(set! thing -a 2) is nicer than (set! (.-a thing) 2) IMHO

borkdude16:11:06

maybe Clojure should support it as well 😉

thheller16:11:04

set! is a weird beast 😛

dnolen16:11:58

@borkdude I think maybe Fogus did that short-hand bit?

borkdude16:11:44

in JVM Clojure you mean? I don't know btw

dnolen16:11:46

I mean the ClojureScript behavior

dnolen16:11:33

so I did that

dnolen16:11:02

yeah I did it so threading would work for all the mutable APIs

borkdude16:11:59

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?

borkdude16:11:18

(I'm not linting the test sources)

athomasoriginal17:11:29

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?

dnolen18:11:51

@tkjone on a plane so I can't the see link for some reason - but is the issue that Figwheel has a typo?

athomasoriginal18:11:54

Yes. Figwheel is referencing glog/warn as opposed to glog/warning.

dnolen18:11:11

but the release does more of course

👍 4
athomasoriginal18:11:11

What was interesting is that I only got the warn when using latest CLJS

dnolen18:11:38

REPL support, var existence check, arity checking, return type propagation

🎉 4
👏 4
dnolen18:11:21

and tooling could hook into - we record file / line / column info for each def

mfikes18:11:27

I haven’t sorted out the root cause, but unit tests failed on Windows: https://clojure.atlassian.net/browse/CLJS-3178

dnolen18:11:21

definitely a bit skeptical that 3137 could be the cause at the moment

mfikes19:11:50

Yeah—it seems it could be an unrelated sporadic failure.

mfikes20:11:58

Yes, it was a sporadic failure---rebuilding it causes it to pass.

borkdude21:11:30

weird that it can randomly fail. we have problems with advanced compilation on JVM11 + boot (although the errors there are not random)