This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-08
Channels
- # aleph (4)
- # beginners (5)
- # cljs-dev (21)
- # clojure (155)
- # clojure-dev (3)
- # clojure-italy (10)
- # clojure-losangeles (3)
- # clojure-nl (2)
- # clojure-russia (5)
- # clojure-spec (42)
- # clojure-uk (11)
- # clojurescript (170)
- # code-art (1)
- # component (3)
- # core-async (28)
- # cursive (70)
- # data-science (3)
- # datascript (1)
- # datomic (28)
- # emacs (6)
- # gorilla (1)
- # graphql (2)
- # jobs (1)
- # lein-figwheel (4)
- # lumo (7)
- # off-topic (13)
- # om (63)
- # parinfer (66)
- # planck (1)
- # re-frame (22)
- # reagent (2)
- # ring-swagger (53)
- # rum (3)
- # sql (13)
- # test-check (2)
- # unrepl (48)
- # vim (8)
- # yada (33)
Looks like the browser field support I added in Closure might be going in today
I guess I’ll take this one as a compliment too: https://github.com/google/closure-compiler/pull/2604#pullrequestreview-54993997
@anmonteiro heh, cool
^ this just went in
@dnolen the Closure default is "browser", "module", "main"
I wonder if we should provide a CLJS option to override it
or just set a nice default
I think it’s a reasonable default for us because we don’t process files with Closure anymore under :target :nodejs
it’s also what Webpack does
the "module"
one is the one I’m concerned about
I think we can roll with it and see what feedback we get
this + @juhoteperi’s UMD patch should make for an even nicer experience overall
sounds good to me, I’ll definitely have some time this Friday to work on our own Closure artifact. Before that I’ll probably cut a release to address these latest :modules issues and the js-obj thing.
@dnolen would also be nice if you could cut a Closure Library release. I can take over putting together a patch that upgrades it
oh right, did we make a ticket for that? If not feel free to make one and assign it me.
I forgot 🙂
making one now