This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-04
Channels
- # announcements (3)
- # babashka (14)
- # beginners (151)
- # calva (14)
- # cider (9)
- # clj-kondo (24)
- # cljdoc (12)
- # cljs-dev (195)
- # cljsjs (3)
- # cljsrn (13)
- # clojars (12)
- # clojure (234)
- # clojure-dev (3)
- # clojure-europe (9)
- # clojure-greece (1)
- # clojure-italy (2)
- # clojure-japan (4)
- # clojure-nl (4)
- # clojure-spec (89)
- # clojure-taiwan (1)
- # clojure-uk (16)
- # clojuredesign-podcast (2)
- # clojurescript (17)
- # conjure (11)
- # core-async (4)
- # core-typed (31)
- # cursive (9)
- # datomic (8)
- # emacs (17)
- # figwheel (1)
- # fulcro (5)
- # ghostwheel (42)
- # graphql (3)
- # hugsql (5)
- # jackdaw (3)
- # jobs-discuss (93)
- # joker (4)
- # meander (6)
- # mount (1)
- # off-topic (23)
- # pathom (10)
- # re-frame (23)
- # reitit (7)
- # remote-jobs (18)
- # shadow-cljs (153)
- # spacemacs (24)
- # sql (30)
- # tools-deps (14)
- # vim (12)
- # xtdb (1)
@bhauman hrm, I can't reproduce https://clojure.atlassian.net/browse/CLJS-3258 with either master or 773
I couldn't reproduce this one either https://clojure.atlassian.net/browse/CLJS-3253, I made something minimal no warnings for me
both of seem like issues that were fixed sometime ago - like you're not running the version of ClojureScript you think you are - but that may be a bad hunch
@dominicm I don't think you added whether this ticket was a regression or not https://clojure.atlassian.net/browse/CLJS-3255?
@dnolen hmmm thats really strange about https://clojure.atlassian.net/browse/CLJS-3258 , as it was reported to me, and then I reproduced it twice in 773 in two separate builds
@dnolen every version I checked was broken, I got a different error at some point. I think it was arity, but not sure.
so I can reproduce this by switching the type (cljsjs or node) of dependency for a given library
in one case reagent is compiled referencing a node_module, and in another it is compiled referencing a global React
the waters are getting muddied right now by this description, let describe how I think it can actually go wrong.
1. The switch to :target :bundle
(and installed React into node_modules
everything will be recompiled everything will be cached on a new path
I'm just trying to describe a minimal reproducer, let's just ignore all the things that can go wrong
2. what happens is that if the user never runs the install step - they will cache something that points to CLJSJS
the order may change what gets cached - but in the end it doesn't really matter, they all look like 2.
more specifically a library that exists outside of the project like reagent gets cached that way
so here's the thing - I don't actually see any good answers to this problem yet - let's point out some basic assumptions
1. Realated, AOT Cache can't understand macro time configuration because it is file specific, not build specific
2. AOT Cache caches along build configuration computed path only, no file specific stuff as stated in 1.
3. Whether we use node module or CLJSJS is in fact exactly the same same problem as 1., a file specific thing
well it points a bunch of prior choices that make it appear incompatible with a simple caching strategy
yes cljs.main
specifically designed for people who are going to audit their deps because we don't care about the macro build time problem
so we're already just saying you're on own - I don't really care that much about this caching problem and order stuff because it's a one time thing
but breaking 4.
is not as bad it sounds - it's more disciplined and would in fact catch simple mistakes
really 4 is just :enforce-deps
- either :install-deps
is true, or the libs are present at the top level
this means it's not possible to use Reagent w/o installing the deps first - because you're saying they must come from there not elsewhere
just noting that changing caching is quite unattractive because you would be generated useless cache files while you're changing your deps at the beginning of the transition
which isn't generally true for Clojure(Script) stuff, just libs that don't enforce one or the other
if the code for requiring the cljsjs dependency and the node dependency was rendered the same in the output this isn’t a problem
I’m saying that if this line
reagent.impl.component.global$module$react = goog.global["React"];
there are problems with backward compatibility here, which is a real practical problem
for :bundle
npm_deps.js
is dev time only, so the door remains open for DCE improvements later
I think the blocker here is that many foreign libs are probably packaged expecting to be global?
fixing up a bunch of libraries when you're transitioning away doesn't sound very valuable
@juhoteperi I think worth pondering dropping the Reagent explicit dependency on cljsjs/react
users can always add it
@dnolen I am really surprised by this. Non-npm users are supposed to manually maintain the cljsjs deps and versions of all the libs they use? non-npm is a significant proportion of users afaik
why not fix this similarly to how shadow has done? ie new compiler opt something like :ignore-foreign-libs-in-deps
. it could default to false
I think pointing to both things creates more problems than it's worth as the backlog will show
@bhauman I think the simplest answer is to just have libraries just choose one dependency
@dnolen Yes, I've been planning to drop the cljsjs dependency
Probably before final 1.0 release
@dnolen I am really surprised by this. Non-npm users are supposed to manually maintain the cljsjs deps and versions of all the libs they use? non-npm is a significant proportion of users afaik
why not fix this similarly to how shadow has done? ie new compiler opt something like :ignore-foreign-libs-in-deps
. it could default to false