This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-20
Channels
- # announcements (1)
- # bangalore-clj (27)
- # beginners (82)
- # boot (4)
- # chestnut (1)
- # cider (22)
- # cljs-dev (26)
- # cljsrn (4)
- # clojure (118)
- # clojure-dev (18)
- # clojure-italy (2)
- # clojure-losangeles (1)
- # clojure-nl (2)
- # clojure-russia (1)
- # clojure-spec (15)
- # clojure-uk (125)
- # clojurescript (61)
- # core-async (74)
- # cursive (2)
- # datomic (41)
- # duct (6)
- # editors (7)
- # emacs (3)
- # events (1)
- # figwheel-main (3)
- # fulcro (111)
- # hoplon (11)
- # jobs-discuss (97)
- # lein-figwheel (99)
- # off-topic (34)
- # onyx (4)
- # parinfer (9)
- # pedestal (4)
- # precept (2)
- # re-frame (5)
- # reagent (2)
- # reitit (4)
- # ring-swagger (11)
- # shadow-cljs (104)
- # spacemacs (4)
- # tools-deps (19)
- # vim (8)
- # yada (15)
Setting :parallel-build
to true
is giving me non-deterministic :advanced
artifacts, with small differences in ordering and names within the generated js.
This is understandable, but is it an expected/known behavior?
@aisamu :parallel-build
builds using multiple threads while honoring the dependency partial order. That would theoretically cause gensyms or other stuff that depends on compilation state to vary non-deterministically.
I believe I have found a bug in the ClojureScript compiler integration with npm; what would be the best way to confirm and report?
what was that talk about immediate feedback where the speaker moved a slider and changed a tree animation?
@urbanslug Sounds like something from Bret Victor
Here's my finding. I'm using the semantic-ui-react library (https://www.npmjs.com/package/semantic-ui-react) imported through NPM. The package gets downloaded fine and it looks like everything works well on the server-side rendering of my application. However, the client-side dies at load-time with the following error:
Error: Undefined nameToPath for module$Users$gary$sparrho$seshat$_gecko$node_modules$semantic_ui_react$dist$es$addons$Confirm
I have cleaned everything multiple times etc. I have dug a little bit in the generated files, and on the server-side it looks like we're using the node_modules folder directly (which makes sense as the target is :nodejs
). The file structure is a bit weird to me for this particular module as we have:
$ tree
.
โโโ addons
โ โโโ Confirm
โ โ โโโ Confirm.js
โ โ โโโ index.js
Looking into Confirm.js
there is a bunch of code that ends with export default Confirm;
. The index.js
file however is more interesting:
$ cat Confirm/index.js
import _default from './Confirm';
export { _default as default };
$
I'm not familiar index.js
file is there to provide the name Confirm
as an alias of the Confirm.Confirm
provided by the Confirm.js
file. Why they have that directory at all rather than just addons/Confirm.js
(which seems to be the pattern in sibling directories of addons
) is beyond me.
After a bit of grepping through the generated code on the client side I have found some confirmation that this is a supported pattern, to some extent. The "closurified" version of index.js
looks like:
cat compiled/out/node_modules/semantic-ui-react/dist/es/addons/Confirm/index.js
goog.provide("module$Users$gary$sparrho$seshat$_gecko$node_modules$semantic_ui_react$dist$es$addons$Confirm$index");
goog.provide("module$semantic_ui_react$dist$es$addons$Confirm$index");
goog.provide("module$semantic_ui_react$dist$es$addons$Confirm");
goog.require("module$Users$gary$sparrho$seshat$_gecko$node_modules$semantic_ui_react$dist$es$addons$Confirm$Confirm");
var module$Users$gary$sparrho$seshat$_gecko$node_modules$semantic_ui_react$dist$es$addons$Confirm$index={get default(){return module$Users$gary$sparrho$seshat$_gecko$node_modules$semantic_ui_react$dist$es$addons$Confirm$Confirm["default"]}}
$
Looking around in the generated files it looks like, generally speaking, whenever there is a file that says export ... as mod
, the CLJS compiler (I assume?) adds two goog.provide
to calls: one with the full path on my hard drive, and one with the relative path from the node_modules
folder. In this case there are three entries, which makes me believe there may be some special handling for this pattern (`export ... as default`?) which is missing the "also do the full path" thing.
This is all happening with :optimizations :none
. I have not tried with more advanced optimizations yet. Does that look like a bug in CLJS ? If so I'll get to work on a minimal repro case.@mfikes YES!!! Found it https://www.youtube.com/watch?v=PGDrIy1G1gU
We're not using reagent. We're currently using the cljsjs version of semantic-ui-react and it works fine, but I'm trying to add other npm deps that are not in cljsjs and it looks like they can't find each other (e.g. react-responsive-carousel from npm can't find React from cljsjs), so I'm trying to move all node deps from cljsjs to npm-deps.
My problem seems directly related to https://dev.clojure.org/jira/browse/CLJS-2205 and that seems to be the one adding what I see as half of the solution.
Is there a way I can force the CLJS compiler to load react
before react-dom
from :npm-deps
?
I'm inspecting my cljs final bundle and there is a lot of clojure.test.check
on it. How to remove it from my bundle? I'm not using it anywhere (maybe it's loaded on the classpath when I call the cljs.main build command)
@ghopper it should figure that out from react-dom using goog.require and react using goog.provide, I think. How is your project set up?
react-dom
doesn't actually depend on react
, though an error is thown if it's loaded before react
.
I just have both in my :npm-deps
, and they're used by reagent
.
I have :exclusions
for cljsjs/react
and cljsjs/react-dom
for reagent
.
I've had a pretty terrible time trying to mix cljsjs with npm-deps so far. I'm actually in the middle of trying to move away from that and move everything to npm-deps. I'm not using reagent though; not sure how you can get it to see the npm-deps versions.
That's what I'm doing as well. ๐ I'm trying to replace reagent
's react with :npm-deps
.
It doesn't have a problem seeing the :npm-deps
version, there's just a load order problem.
Manually requiring it in my namespace has no effect.
You'd have to actually use them in a way that the compiler can't figure out is useless? ๐
There's no DCE going on. This is all in development.
If you go (:require react)
it will require it as the react
cljs var, but given the set-up in cljsjs (https://github.com/cljsjs/packages/blob/master/react/resources/cljsjs/react/common/react.ext.js) I suspect reagent will expect React to be available as js/React
?
Or not: https://github.com/reagent-project/reagent/blob/master/src/reagent/impl/component.cljs#L3 I'm out of ideas then; what error message do you get?
Yeah, reagent shouldn't have an issue with it.
I'm getting this from React: https://reactjs.org/docs/error-decoder.html?invariant=227
I am trying to use the expound
printer with clojure.spec.test.alpha/summarize-results
but it seems like it does not kick in
anybody noticing the same?
@richiardiandrea What code are you using?
I am using
@richiardiandrea Keep in mind summarize-results
does not utilize s/*explain-out*
(binding [s/*explain-out* (expound/custom-printer
(merge {:print-specs? true}
(when *gen-test-colors*
{:theme :figwheel-theme})))]
(-> (tcs/run-spec-checks! `api/ok-response opts)
(cljs.spec.test.alpha/summarize-results)))
oh that is why
that explains everything
let me make it clear in the README
summarize-results
is for printing the results from check
, which contains more data than just the explain-data that is returned from explain-data
, used in explain
etc
I will use expound/explain-results
then
Right now, summarize-results
isnโt extensible, but I wonder if thatโs something that could change. Itโd be nice to โinstallโ expound once and get the behavior you were expecting
It is odd because the check
results do not seems to take into consideration explain-out
at least here, the js/Error
message I see is always starting by: Specification-based check failed
no matter the content of it
Yep, the whole check
system doesnโt connect with the way printing works for explain
too bad...
I can understand why itโs different, but itโd be nice to have a parallel system for check so users can register a s/*check-printer*
or something.
definitely