This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-11
Channels
- # beginners (109)
- # boot (61)
- # cider (8)
- # clara (3)
- # cljs-dev (67)
- # cljsrn (5)
- # clojure (96)
- # clojure-argentina (1)
- # clojure-brasil (2)
- # clojure-greece (10)
- # clojure-russia (114)
- # clojure-spec (51)
- # clojure-uk (45)
- # clojurebridge (2)
- # clojurescript (139)
- # cursive (18)
- # data-science (1)
- # datascript (2)
- # datomic (13)
- # dirac (2)
- # emacs (5)
- # events (1)
- # javascript (2)
- # jobs (1)
- # juxt (3)
- # off-topic (62)
- # om (10)
- # onyx (12)
- # perun (7)
- # ring-swagger (7)
- # specter (21)
- # test-check (5)
- # untangled (16)
- # utah-clojurians (1)
- # yada (2)
@dnolen pending tickets for me are: http://dev.clojure.org/jira/browse/CLJS-1822 and http://dev.clojure.org/jira/browse/CLJS-1847
@anmonteiro yeah testing 1847 - what’s the idea behind 1822?
@dnolen hrm, say React, for example, has dev and production bundles. The use case is for the Closure Compiler to process the production bundle when compiling with :simple
or :advanced
@anmonteiro but what about foreign libs that can pass through advanced?
I don't understand your question
happy to add more context to the ticket too
the intent of this patch is for JS modules only
if you want your :file
to pass through :advanced
, don't specify a :file-min
is the idea that :file-min
is a thing for JS modules where we know :advanced
won’t work
I'll provide more context in the ticket
AFAIK there's already a :file-min
option in foreign-libs
this patch is just mimicking that for foreign libs that are JS modules
@anmonteiro can’t be true
oh OK, I get what you're saying
@dnolen updated the description. Let me know if anything is still not clear http://dev.clojure.org/jira/browse/CLJS-1822
@anmonteiro so the patch doesn’t affect modules that can be advanced compiled?
not at all. It just uses :file-min
(if specified) as a drop-in replacement for the one in :file
to go through Closure Compiler processing
the easiest example is to think of React. It has a bunch of invariants in the non-minified version which we don't want to include in our production builds
so when building for production, we want to use react.min.js
instead
(both still go through the Closure Compiler. but the production version is used when we're compiling with :simple
or :advanced
)
of course you know this, but this is not about minified or not, since everything goes through :advanced
in the end anyway. It's about libs which have different dev/prod versions
again, let me know if I can make any of this clearer
if you have :file-min
you don’t want it to go through Closure - it will likely just cause trouble
why though?
because e.g. require
s might be named something else?
the file is something which has already passed through some other minification process
right, but does it matter?
the only thing that I can think that might break is externs for some internal stuff
oh OK, so this could probably be my misunderstanding of what :file-min
was supposed to do 🙂
I get what the problem is. feel free to disregard the patch for now
but say that React can be processed by the Closure Compiler. We still need a story for production builds there
i.e. I don't want to be using the development version of React in my :advanced
builds
I’m fine with the big idea, it’s something I’ve been thinking about - but it needs to be more careful
and they differentiate the checks based on process.NODE_ENV
or whatever it's called
agreed
@dnolen FWIW in the React case, it works perfectly going through :advanced
in the Circle Color project
I'm trying it out with my patch to CLJS-1822 applied
consuming react.min.js
and react-dom.min.js
yeah, this is just a first attempt
probably should try to do the same with other libs
just got the Circle Color project working fully with :advanced
/ cc @juhoteperi
needed to add some synthetic event externs
(also working with the CLJS-1822 patch and :file-min
)