This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-31
Channels
- # architecture (5)
- # beginners (35)
- # boot (150)
- # cider (1)
- # clara (7)
- # cljs-dev (131)
- # cljsrn (10)
- # clojure (76)
- # clojure-austin (3)
- # clojure-berlin (1)
- # clojure-brasil (1)
- # clojure-chicago (2)
- # clojure-dusseldorf (1)
- # clojure-italy (30)
- # clojure-nl (2)
- # clojure-russia (40)
- # clojure-serbia (2)
- # clojure-spec (25)
- # clojure-uk (13)
- # clojured (2)
- # clojurescript (106)
- # core-async (29)
- # datascript (65)
- # datomic (38)
- # emacs (8)
- # funcool (8)
- # hoplon (6)
- # jobs (3)
- # klipse (93)
- # luminus (16)
- # lumo (4)
- # off-topic (2)
- # om (11)
- # onyx (13)
- # pedestal (4)
- # protorepl (3)
- # re-frame (40)
- # reagent (31)
- # ring (6)
- # ring-swagger (4)
- # slack-help (5)
- # spacemacs (13)
- # untangled (17)
- # vim (2)
Resolving relative filepaths against classpath directories is easy when using clojure.java.classpath
But what I think is even simpler, is just using foreign-library :file
for output path if it is set and relative
A patch using that solution attached: http://dev.clojure.org/jira/browse/CLJS-1922
@juhoteperi I'm not sure that's a good solution though
I tried to think a case where it wouldn't work but couldn't come up with one
from the little testing I did so far, using a relative path doesn't seem to work when consuming node modules
which is why the guide uses getAbsolutePath
in this section: https://clojurescript.org/guides/javascript-modules#node-modules
I haven't looked at the code to know why that's the case though
your patch wouldn't break anything, I suppose, but the above use case wouldn't be possible with Boot?
Hmm strange, but, that would still work with my change, as it checks if the :file
is relative before using that
^ exactly
IF the node_modules
is outside of source/resource-paths, I think absolute path would work with Boot
ah that's right
But if node_modules are inside source/resource-paths, or a task adds them to the fileset, absolute paths won't work
-source
calls -url
and -url
always coerces paths and files to URLs, which will make them absolute
So I think classpath relative paths should work in that example
hrm, so there's this problem in several Node modules in that they rely on JS hoisting of functions and use a variable before it has been defined in the fiel
the patch I submitted to React addresses that for React's particular case, but the Closure Compiler doesn't rely on hoisting of those exported functions
this causes undefined reference errors
I'm not sure if this should be addressed in GCC or by every module author out there
this issue seems related but addresses a different consequence: https://github.com/google/closure-compiler/issues/2240#issuecomment-273946670
also filed the issue with GCC: https://github.com/google/closure-compiler/issues/2265
@juhoteperi btw, there's a new option :closure-module-roots
that Boot may have to set if using relative paths? I'm just speculating because I don't know what it does
@anmonteiro Doesn't affect the logic to build relative output paths for foreign modules at all. I think it is just for Closure compiler.
@anmonteiro that’s just to get Google Closure to resolve modules correctly
@dnolen trying to wrap my head around some spec stuff in cljs, I don't quite understand why this swap!
is there
https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/spec.cljc#L59
yes I know but it is the only time cljs.spec/runtime-ref
is accessed (from the cljs/spec.cljc
that is)
it might be used at some point in the future when we want the compiler/analyzer to look at it
I have started getting warnings like this with the latest (1.9.456) cljs compiler:
WARNING: Use of undeclared Var uxbox.main.ui.users/js at line 21 /home/uxbox/uxbox/frontend/src/uxbox/main/ui/users.cljs
WARNING: Use of undeclared Var uxbox.main.ui.users/js at line 21 /home/uxbox/uxbox/frontend/src/uxbox/main/ui/users.cljs
Interesting, I noticed that too in Devcards but I didn't isolate the problem and thought I was doing something wrong
Right. What I said is meant to support your conclusion too
I just didn't report it because I was messing around with new JS module stuff
same issue here https://github.com/plumatic/schema/issues/380
@dnolen I got Om Next working with React from node_modules
last night
https://github.com/anmonteiro/om/commit/686921531c7bcbbd75804e6b9240b12d92eaaa5f
This made me think about one issue with the current node_modules
support, which is: how do library authors lock in a particular version of, say React?
and 2) how do library users override that dep at their own risk?
right, that also makes sense
so library authors would develop against something that users would need to provide?
just like it works in the JS world
gotcha
@anmonteiro I also built Rum/Sablono app with React from NPM. Couldn’t use a number of other deps directly from NPM because they all have stupid errors like the one you’ve reported in React recently 😞
I had the same problem yesterday at work too
wanted to try and use something from node_modules
but it had the order issue
I think this is ultimately an issue with GClosure
@roman01la I've opened an issue there and Chad acknowledged it, so we might see a fix soon (Chad is the person who's been working on all the JS module support PRs for GClosure)
@anmonteiro following JS quirks is a bad idea, bad it would really help :thinking_face:
right
@roman01la fortunately linters can detect that particular case now
(even if they don't fix it in Closure)
@anmonteiro if we end up having deep support for Node.js deps, it’ll come after we solve the direct CommonJS require problem
but yes I’ve considered having support for writing package.json deps in deps.cljs or something like that
right, that makes sense
right now I'm working around it like this: https://github.com/anmonteiro/om/commit/686921531c7bcbbd75804e6b9240b12d92eaaa5f#diff-0a1425bd66240468daf4c256a411ce75R47
^ but it's really hacky and very brittle
needless to say these are only experiments, I have only been tinkering with it and not using it anywhere
Right
@dnolen that doesn't seem wrong to me, people can still use the compiler without Node if they don't use this functionality
and if they want to consume Node modules, they'll have it installed anyway 🙂
I can't seem to repro it anymore
@jr it may be an analysis cache problem, so useful to determine if it only happens w/ cache
yeah we write out tag info into the cache for return types, so maybe the problem is there somehow
could it be caused by the upgrade?
i.e. new CLJS trying to read an analysis cache written by old CLJS?
that makes sense to me, because I can't repro on this computer after a fresh clone
but it happened to me on my other computer which already had the repo
@anmonteiro Did you try Schema? I got error about RegExp
from Schema with Boot-cljs (so no cache)
not yet
might be a different issue altogether
do you have a repro?
Just a work project depending on Schema, nothing more specific
boot-cljs caches analysis in ~/.boot/cache
. I had that same RegExp
warning which is now gone
@jr No it doesn't
Huh, the warning is gone for me too
is this because people switched ClojureScript compiler version without starting a clean build?
seems like that's what happened
although you're not really supposed to "clean" your build if you're using boot
Really strange
Well, Boot uses JVM pid to generate different temp dirs for each JVM process.. so it is in theory possible that new processes would have got same pid as previous Boot process
I don't see other ways Boot-cljs could have cache left around from previous runs
Oh, and Boot cleans the temp directory when starting
Anyway, can't reproduce
btw, boot-cljs
is under the Boot org now?
@anmonteiro Repo yes, I'm probably keeping the group and artifact-id same as I can't decide on new ones
what's wrong with boot/boot-cljs
?
Currently boot
org is only for the core libs, though I guess that's not necessarily a problem. Another problem is that the tasks use group-id.artifact-id
naming convetion for the main namespace, and boot.boot-cljs
is not very good name... Perhaps it should just be boot-cljs.core
.
Naming is hard and renaming existing things is extra hard 😞
@anmonteiro Hmm, on my case it is not cache
@niwinz awesome, do you have a minimal repro?\
we haven't been unable to repro it
It happens on https://github.com/uxbox/uxbox/tree/master/frontend repo