This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-13
Channels
- # beginners (28)
- # boot (3)
- # clara (9)
- # cljs-dev (127)
- # clojure (82)
- # clojure-belgium (3)
- # clojure-italy (7)
- # clojure-russia (2)
- # clojure-spec (4)
- # clojure-uk (2)
- # clojurescript (351)
- # data-science (3)
- # datascript (1)
- # datomic (24)
- # fulcro (15)
- # jobs (3)
- # juxt (16)
- # off-topic (2)
- # onyx (18)
- # parinfer (1)
- # pedestal (3)
- # perun (6)
- # re-frame (14)
- # spacemacs (20)
I'm unable to use :npm-deps to use @blueprintjs.core. A warning is thrown and I can see that :js-dependency-index is missing a require.
Would a JIRA ticket be welcome? I have a test which shows the problem. Not hard to describe here if that's preferred. (will make a thread on this to avoid being noisy)
(deftest test-cljs-XXXX
(test/delete-node-modules)
(spit (io/file "package.json") "{}")
(let [cenv (env/default-compiler-env)
out (.getPath (io/file (test/tmp-dir) "test-npm-deps-order"))
{:keys [inputs opts]} {:inputs (str (io/file "src" "test" "cljs_build"))
:opts {:main 'npm-deps-test.test-cljs-XXXX
:output-dir out
:optimizations :none
:install-deps true
:verbose true
:npm-deps {:react "15.6.1"
:react-dom "15.6.1"
:react-addons-css-transition-group "15.5.1"
"@blueprintjs/core" "1.24.0"}
:closure-warnings {:check-types :off
:non-standard-jsdoc :off}}}]
(testing "@blueprintjs can require tslib"
(test/delete-out-files out)
(test/delete-node-modules)
; NOTE: Build warns about the issue
(build/build (build/inputs (io/file inputs "npm_deps_test/bp_requires.cljs")) opts cenv)
(let [tslib-module-entry (get (:js-module-index @cenv) "tslib")
comp-module-entry (get (:js-module-index @cenv) "@blueprintjs/core/dist/common/abstractComponent")
comp-dependency-entry (get (:js-dependency-index @cenv) (:name comp-module-entry))]
; NOTE: We can see in the deps index that the require was missed
(is (contains? (set (:requires comp-dependency-entry)) (:name tslib-module-entry))))))
(.delete (io/file "package.json"))
(test/delete-node-modules))
(ns npm-deps-test.test-cljs-XXXX
(:require ["@blueprintjs/core" :as blueprintjs]))
This is the closure compile warning WARNING: JSC_JS_MODULE_LOAD_WARNING. Failed to load module "tslib" at /Users/olivergeorge/repos/clojurescript/node_modules/@blueprintjs/core/dist/common/abstractComponent.js line 9 : 4
And this is the test output
@blueprintjs can require tslib
expected: (contains? (set (:requires comp-dependency-entry)) (:name tslib-module-entry))
actual: (not (contains? #{"module$Users$olivergeorge$repos$clojurescript$node-modules$$blueprintjs$core$dist$common$utils" "module$Users$olivergeorge$repos$clojurescript$node-modules$react$react"} "module$Users$olivergeorge$repos$clojurescript$node-modules$tslib$tslib"))
@olivergeorge looking
Closure can’t understand tslib’s UMD wrapper
wait my assessment is wrong
the above is true, but there’s also a bug in CLJS and this should work with the latest Closure
fixing
Thanks @anmonteiro. I was trying using clojurescript master. Seemed like tslib was coming though okay by itself.
the UMD problem is definitely happening
but we should be able to get around it, however we’re having another problem
Thanks for looking.
@olivergeorge there might still be issues with the UMD thing (that need to be fixed in Closure), but your issue is fixed here: https://dev.clojure.org/jira/browse/CLJS-2318
Thanks again
Confirming that improves my situation. No more warnings and the tslib related errors are gone.
(still not a clean build but I wasn't expecting magic :-)
next one seems to be tether's wrapper. i get "require not defined" after building. i assume another wrapper quirk https://unpkg.com/[email protected]
i'll head back to #clojurescript for other q's
I’m thinking of filing an issue because alter-meta! does not work/behave like Clojure. Thought I would check here first after reading this https://dev.clojure.org/jira/browse/CLJS-1511
@alex-dixon there’s no reason for alter-meta!
to work (precisely like Clojure)
we have a few affordances, but these are only for completely static cases (testing, cross module boundaries)
Hm. Ok
@alex-dixon metadata and vars are two completely separate things
we just a do a tiny bit work to create the illusion for a couple of specific useful cases as I’ve said above
Hm. Ok
Is the docstring for alter-meta! considered accurate? “Atomically sets the metadata for a namespace/var/ref/agent/atom to be: (apply f its-current-meta args) f must be free of side-effects”
Is altering the metadata of a var possible at runtime?
Sorry. I don’t understand “reified vars” and assumed it would be different from “var”. I thought reified vars don’t exist in CLJS
Also confused I think by how I can do (meta foo) where foo is…something I’ve defined with def…and get CLJS metadata
Ok. Thank you
ClojureScript doesn’t have vars because it doesn’t make much sense with advanced compilation, code size, and performance as primary values
it’s turned out that a good many of the dynamic features of reified vars can be accomplished by other means
so as long as what you’re doing doesn’t fundamentally require runtime hijinks - there’s often another way to accomplish the same thing
In one version of what I’m trying to do, I can add the meta at compile time in a macro. Only thing is that there’s one symbol that I want to resolve to a value and I don’t know how to do that. So I changed my approach to try to have that code run at runtime instead
@alex-dixon also it’s possible that what you want is bootstrapped ClojureScript
Maybe I can’t use metadata to store…metadata…because one of the values I need is realized at runtime, and I can only add metadata at compiletime, but…if I had the namespace and the symbol in the metadata, could I obtain the value from it at runtime?
instead of talking about solutions - just state at a high level what you are trying to accomplish
I’m trying to make Precept manage multiple sessions (instances of Clara’s LocalSession). I wrote the initial code with references to global atoms, which worked fine if the library is only concerned about a single session . But now I want to manage multiple and pass them through everywhere. There’s data I need to associate with the session instances themselves. I don’t want to pass around a map because a lot of the code expects a LocalSession (and thought it would be the appropriate use of meta to do (meta #‘my-session) and get data back for its schema and a few other things. So, I’d prefer to pass around instances at least
Thank you
if your design work is leading you to want to a do a whole bunch of metaprogramming you can’t possibly be pursuing the right thing
I have all the data I need for a particular session inside the macro that defines it. The alternative seems a registry/lookup
Yeah…I built on top of clara which uses macros a bit for DSL, compiling a rules engine into CLJS
I don’t know. I thought it would be more pure functiony and less side-effecty
It’s incredibly well done imho if you ever have the time
They designed it to be parallelizable. Part of the motivation for what I’m doing is to take advantage of that and have everything work in Clojurescript also
No clear reason why this was abandoned: https://github.com/rbrush/clara-storm
A ton
But so is a lot of things, and I think there’s a lot of potential. Who knows though I guess
Thanks 🙂
it looks like js/process
is getting wiped out with {:target :nodejs :optimizations :simple}
settings in the latest CLJS build (1.9.854)
https://github.com/rads/cljs-bug
@rads Fixed in master: https://github.com/clojure/clojurescript/commit/4f8dde57e01b5f3b23bf454e6c414896cf806e78
ok only one :modules
thing left, should be easy the dep order thing - will try to resolve that tomorrow
master has some changes to how we output under :none
so that could use some testing under browser and Node.js
assuming :modules
thing gets sorted tomorrow, can expect a release + updated docs / announce then
@dnolen is that the foreign libs thing?
the thing that’s missing
should be quite easy to fix, I think module-graph should not assume the inputs order is correct
can’t actually repro that ^
I’ll attach a test case to CLJS-2309 that shows I can’t repro anymore
hrm actually I might be wrong here because I can’t repro with 1.9.854 either
anyway, test case patch attached to CLJS-2309
I think that should reproduce the issue (if there was one), but the test passes