This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-06
Channels
- # beginners (90)
- # boot (83)
- # cider (39)
- # clara (4)
- # cljs-dev (124)
- # cljsrn (10)
- # clojure (208)
- # clojure-boston (1)
- # clojure-italy (13)
- # clojure-nlp (3)
- # clojure-russia (34)
- # clojure-spec (63)
- # clojure-uk (101)
- # clojurescript (65)
- # community-development (13)
- # copenhagen-clojurians (1)
- # core-async (1)
- # cursive (24)
- # datascript (1)
- # datomic (65)
- # emacs (20)
- # graphql (20)
- # hoplon (21)
- # instaparse (18)
- # jobs (5)
- # jobs-discuss (2)
- # leiningen (8)
- # luminus (32)
- # midje (1)
- # mount (3)
- # off-topic (18)
- # om (10)
- # parinfer (6)
- # pedestal (2)
- # planck (2)
- # precept (22)
- # protorepl (7)
- # re-frame (45)
- # reagent (9)
- # ring (1)
- # ring-swagger (4)
- # rum (2)
- # spacemacs (5)
- # sql (2)
- # unrepl (13)
- # untangled (8)
- # yada (5)
@juhoteperi so what are you suggesting?
what did this fix? https://github.com/clojure/clojurescript/commit/12c142c2a3c6c59f6b4b646887a72c2a265f3832
oh hrm I guess there’s context in the issue
util/relative-name
is still not quite right. I’m fixing & adding test cases
actually can’t really add tests because cross-platform 😞
@dnolen hopefully last round of fixes for NPM deps & JS modules on Windows https://dev.clojure.org/jira/browse/CLJS-2177
had to spawn a Windows VM 🙂
this was getting under my skin
@anmonteiro left a question on the issue
answered
I tested the NPM deps thing in a folder that had spaces on purpose
@anmonteiro one last question on the issue
OK hold on, string-based requires don’t work because of a backslash issue too
putting that in the same patch
@dnolen OK fixed that too
FYI, the change now is to replace the paths in the module graph :provides
with forward slashes so people can require e.g. "react-dom/server"
and have that work on Windows too
@anmonteiro ok, will look at that in the new patch
it’s the one-line change in module_deps.js
(I replaced the patch with the new one, if that wasn’t clear)
you’re right
where did it go wrong
@dnolen fixed now, sorry
I keep outputting patches to the samples directory when I’m running the string-based requires example
let me create a ticket to add tests for that
@dnolen the follow up to 2180 is to make sure that this string gets added to cljs_base: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1275
I couldn't get it to work without any terrible hacks
I think the module graph doesn't know to assign it to a module
That causes a whitespace bundle to to a request for cljs_deps.js
when one does not exist
@anmonteiro just seems like a bug, cljs.modules-graph
assumes ijs
is a map - file an issue
@dnolen I’m happy to fix but need more info. should it handle the case that source is a string or should we pass it an ijs?
asking because I tried passing ijs but didn’t know what to put in :provides
or :url
and throws without it
@anmonteiro well we have to compute something for that via deps/-provides
wouldn’t e.g. cljs.core
need to depend on it though for it to be put at the beginning of the bundle?
gotcha, let me try to make it work
“fix up string compiler inputs” means making ijs out of them?
as long as the :provides
name in the expanded modules graph is the same as the one we compute later is the same we’re good
like we do for some node inputs
right, so do we need a different strategy?
we use this all over the place, probably worth making a helper
(->> (util/content-sha js)
(take 7)
(apply str))
thanks, let me try and make it work 👍
hrm this doesn’t work for only expand-modules
also need to tweak it for module-graph/find-sources-for-module-entry
@dnolen I think we can’t be touching string inputs, and just make cljs.module-graph
operate on deps/-provides
instead of assuming everything is a map?
otherwise this bit won’t work: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1134-L1147
I see
I suppose we’ll have to give it a URL then
when coercing from string input to a map
otherwise errors here: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1152
which is the problem I was having yesterday
@dnolen attached a patch here: https://dev.clojure.org/jira/browse/CLJS-2181
open to better ideas to solve the problem if you have any
@dnolen do you see any drawbacks of using the new resolve
macro when not code splitting?
@dnolen something I noticed too, the resolve
macro expects the symbol to be quoted. is this a hard requirement?
we could easily allow both (resolve 'foo.bar/core)
and (resolve foo.bar/core)
or at least warn/throw for the case we don’t support
that’s what I’d go for too
@dnolen https://dev.clojure.org/jira/browse/CLJS-2182 also noticed that the other macros that have assertions for guarding against this behavior will error before getting there because of destructuring in arguments
patch welcome to fix those cases?
current errors are cryptic, when with simple fixes we can provide the more accurate “arguments should be quoted symbols” message
@anmonteiro patch welcome - yeah there are quite a few macros that must take a quoted symbol and they all suffer from this problem
@dnolen also noticed we don’t have a ns-publics
macro. For compat with Clojure does it make sense to add one?
adding it in another ticket
along with ns-imports
I wonder how hard it would be to support nested requires in ClojureScript
very useful for namespaces like foo.bar
foo.bar.baz
to do like in Clojure (require '[foo.bar [baz])
or whatever the syntax is