This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-10
Channels
- # aleph (3)
- # architecture (3)
- # bangalore-clj (5)
- # beginners (75)
- # boot (75)
- # cider (2)
- # cljs-dev (48)
- # cljsjs (3)
- # cljsrn (17)
- # clojure (125)
- # clojure-belgium (1)
- # clojure-boston (1)
- # clojure-italy (20)
- # clojure-losangeles (2)
- # clojure-spec (73)
- # clojure-uk (34)
- # clojurescript (127)
- # cursive (8)
- # data-science (5)
- # datascript (128)
- # datomic (5)
- # emacs (4)
- # events (3)
- # fulcro (1)
- # jobs (1)
- # jobs-discuss (4)
- # jobs-rus (9)
- # keechma (79)
- # lein-figwheel (2)
- # leiningen (2)
- # lumo (31)
- # om (1)
- # parinfer (61)
- # pedestal (1)
- # planck (1)
- # portkey (31)
- # re-frame (34)
- # reagent (53)
- # ring (3)
- # ring-swagger (13)
- # rum (1)
- # spacemacs (14)
- # testing (1)
- # yada (2)
it looks like the Maven release does have my commits
yep, just confirmed the JAR sources
what a weird release cycle
they cut v20170806 and maven-v20170806 and they’re not cut 1. at the same time 2. from the same commit
put together a patch upgrading it in https://dev.clojure.org/jira/browse/CLJS-2316
I migrated all of Maria & Re-View React deps to use React from npm/node_modules. It worked flawlessly, but compile times for :optimizations :none
Maria builds increased by 3-4x (one build went from 43 to 133 seconds, another from 28 to 118). Then I discovered that the latest React from cljsjs has :global-exports, so I didn’t have to change my code at all, I just got rid of the npm dependency and added [cljsjs/react "16.0.0-beta.2-0"]
. Now compile times are even faster than before, each build runs in 28 seconds.
(unrelated: everything ‘just worked’ migrating from React 15.* to 16-beta, which I didn’t expect, as we make heavy use of its api surface)
and getting rid of all these references to js globals (`js/React`, js/ReactDOM
) is so nice.
@mhuebert :global-exports
doesn't allow proper optimization of JS code etc. which using node_modules and Closure module processing allows
3-4x increase in built times sounds quite a lot, was this for initial compile only or did it affect recompiles also?
@juhoteperi by ‘proper’ optimization do you mean smaller file size / faster, etc., or something else that would cause problems to avoid?
I don't remember seeing much difference when testing Reagent with node modules
@mhuebert Module processes JS code goes through the same advanced optimization pass as Closure JS and Cljs results, this includes Dead Code Elimination etc.
foreign-libs JS files (with :global-exports or not) are included as is
@juhoteperi incremental compiles did not appear to be slow
it seems like the time required for google closure to process React is related to the size of the project it is being added to it looks like processing React/ReactDom took 90 seconds in both cases
Did you try with React 15.6 or 16 from npm?
(I'm not sure if 16 from npm even works, they have changed completely how it is packaged)
Yeah, React 15.6 consists of few hundred JS files plus the dependencies, and Closure has to read and convert all these
@mhuebert I think in the near future we’ll want to pursue a smarter approach to caching for dependencies - node_modules and sources from JARs. Compile these to some other location, and then copy them to :output-dir
).
@dnolen what failure did you get with 2315?
@anmonteiro will paste, running tests again
thanks
@dnolen no need
I forgot to stage the test files….
amending the patch now
replaced the patch
@dnolen I will add a comment to the patch in CLJS-2312, but wanted to check with you that the approach makes sense
It doesn’t munge default
if the var-name has a namespace, because it’s my understanding that those cases will be munged to my.ns.var.default
which is valid in ES5
but if the var-name does not have a namespace we should munge it to default$
because a standalone default
is not valid
@dnolen the test case for this was included in CLJS-1620
and reverting those names to default
serves as a regression test
the reason why I changed those variable names to something other than default
in the first place was because they would throw errors
but let me amend the patch to add a comment, even if only in the commit message
@dnolen OK, patch replaced with an inline comment