This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-18
Channels
- # beginners (16)
- # boot (23)
- # cider (15)
- # clara (29)
- # cljs-dev (86)
- # cljsrn (22)
- # clojars (9)
- # clojure (211)
- # clojure-dusseldorf (5)
- # clojure-italy (21)
- # clojure-sg (2)
- # clojure-spec (4)
- # clojure-uk (12)
- # clojurescript (208)
- # cursive (5)
- # data-science (10)
- # datomic (13)
- # dirac (99)
- # emacs (1)
- # events (2)
- # figwheel (1)
- # fulcro (9)
- # graphql (27)
- # hoplon (50)
- # instaparse (9)
- # juxt (61)
- # keechma (6)
- # leiningen (1)
- # luminus (4)
- # lumo (24)
- # off-topic (22)
- # om (16)
- # onyx (17)
- # parinfer (35)
- # pedestal (3)
- # planck (12)
- # protorepl (8)
- # re-frame (15)
- # reagent (24)
- # ring (1)
- # rum (1)
- # spacemacs (3)
- # uncomplicate (4)
- # yada (3)
also fixed https://dev.clojure.org/jira/browse/CLJS-2326 just now. @dnolen one of these will probably need a rebase once you apply the first one
@anmonteiro appears to be working! able to refer react/react-dom, and also this is the first time I’ve got a :modules build working (previously had some issues with some transitive js-deps which have been sorted out in your recent work)
Alex Miller’s clj
stuff is really quite nice, I’m thinking we should switch our primary docs to it when it’s properly released
we don’t have to talk about rlwrap
anymore, and it’s way simpler to cover deps than project.clj
or Maven
Longer term, I wonder if some of the same magic that clj
uses to search for the “latest” release could somehow lead to something similar that searches for the latest ClojureScript release. (It’s perhaps way to early to get a feel for what something like that might mean.)
But, yeah, just using clj
as it is meant to be used seems like a good idea.
@anmonteiro Do you have any tips on getting IntelliJ to detect Closure-compiler properly? Looks like it only supports pom.xml
file and I think Closure has proper configuration on pom-main.xml
file
is the clj
stuff online somewhere?
nvrmind: found the thread https://groups.google.com/forum/#!topic/clojure/FpMqtNu0TCE
I’m compiling using :optimizations :simple for the first time now with the latest cljs, and I am getting a runtime error that I haven’t seen before: Uncaught TypeError: Cannot read property 'env' of undefined
.
There is just the one file in the stacktrace (the :simple-compiled file). The error comes from fbjs
in node_modules, trying to read process.env
:
var module$Users$MattPro$Documents$sites2017$maria$node_modules$fbjs$lib$emptyObject={};"production"!==process.env.NODE_ENV&&Object.freeze(module$Users$MattPro$Documents$sites2017$maria$node_modules$fbjs$lib$emptyObject);function makeEmptyFunction...
I can avoid the error by running <script type="text/javascript">window.process = {env: {}}</script>
first
@tony.kay when you get a chance could you try master as well - I tweaked how we handle :preloads
, in your case I want to make sure your :modules
stuff is still working wrt. dep order when applying optimization settings
I have noticed this little quirk while trying the string require, which is a bit odd (at the REPL):
(require '"something") ;; there is a quote before the apices
The why is clear, but it feels unidiomatic, should I open an issue or not worth fixing?I have a question, with the advent of the new string require, is there a more concise way to require https://google.github.io/closure-library/api/goog.string.format.html ?
@dnolen FYI looks like my PR to Closure might land today https://github.com/google/closure-compiler/pull/2620
@dnolen if you’re still around, another enhancement patch: https://dev.clojure.org/jira/browse/CLJS-2330
@juhoteperi we could maybe use global exports in node_modules case to fix old style usage
@dnolen this is only for compatibility & consistency with a case that we don’t really expose, but advanced users can poke at
because processing node_modules
under :target :nodejs
doesn’t really work with :none
, but you can use that with :simple
@dnolen Hmm, interesting. Even (def a js/React)
(.createElement a ...)
should probably work as a
would point to module$foo$bar$react
or something, and Closure should take care of renaming the calls?
this would should fix all old style usage as long as people aren’t doing crazy dynamic stuff - in which case don’t really care
Anyway, I already updated to om/rum/devcards/sablono to use new require, but couldn't get tests passing with simple changes. I'll put up PR on each project for commenting and testing.
I think most of the problems with the changes are from code generated from macros that tries to call react/
https://github.com/r0man/sablono/pull/175 https://github.com/tonsky/rum/pull/148 https://github.com/omcljs/om/pull/887 https://github.com/bhauman/devcards/pull/127
There is also lots of warnings from namespaces that use defui
about missing react
namespace
@juhoteperi I've been reading the comments and trying to understand the need for this change, and to know how backwards compatible it is
It will allow users to use the library with both foreign-libs and node modules. Which is not really possible (currently) if library accessess js/React
or other globals.
however making old stuff and new stuff work at the same time will require a bit more work
it would convert all old style foreign libs usage to become new style foreign lib usage
it’s in Closure master :tada: https://github.com/google/closure-compiler/commit/e6e4313941289d17b135901145fd1be90735ccf9