This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-05
Channels
- # aleph (2)
- # beginners (93)
- # boot (9)
- # cider (1)
- # cljs-dev (50)
- # cljsrn (4)
- # clojure (32)
- # clojure-russia (58)
- # clojure-spec (23)
- # clojurescript (146)
- # clojurewerkz (2)
- # component (1)
- # cursive (2)
- # hoplon (163)
- # off-topic (4)
- # om (117)
- # onyx (8)
- # pedestal (1)
- # re-frame (13)
- # reagent (34)
- # spacemacs (17)
- # test-check (1)
- # untangled (3)
@alandipert, @micha: we really should have a js
or clojure
task for our client-side code that is roughly equivalent to javac
on the jvm, and allows the user to have javascript and clojure sources in a project together. of course, there would be some differences due to javascript's super-special approach to dependency management and the fact that the closure compiler is the backend for the clojure compiler. the ideal way to do this probably involves splitting up boot-cljs and factoring out the closure compiler into a separate task...
@dm3 hey, how do i override on!
?
this when-dom
thing is really causing me problems 😞
don’t think i’ve done that before
i’ll have a look
when i look at the output after the hoplon task has run, they're not in the generated ns form
yeah. so boot-hoplon needs to: 1. ignore the illegally-formed deps.cljs files and 2. pass through required javascript dependencies
i do think we should have a js task or something like it where we pass in a manifest of the stuff that is in the deps.cljs file.
from a cohesive standpoint, i want both of these in my sources, just like i can with clojure and java files.
maybe i want to optimize part of my app while writing it in js, or maybe i inherited an app that was written in js and i'm refactoring it to clojure (like i am now).
but why does it need to be? since these files are leaves of the dependency tree since they're part of an app and not a lib, and all belong to the same artifact, why couldn't there simply be a manifest file passed as an argument to a js task.
so in theory, if this wasn't a special case that upset boot-hoplon - and ns+ was happy with javascript deps - adding deps.cljs to the classpath would work.
i did exactly that, but it failed at the time - i now realize this was because they weren't being included because once they got past hoplon ns+ got them instead.
i had to
(->> (boot/fileset-diff @prev-fileset fileset)
(boot/input-files)
(boot/by-ext [".cljs"])
(reduce #(if (= (:path %2) "deps.cljs") % (conj % %2)) [])
(group-by boot/tmp-path))
i did something like that for both hoplon
and ns+
tasks, but additionally, that wouldn't work either since the deps i specified to ns+ wouldn't have been passed through to the ns macro in the resulting cljs file.
on the bright side, i'm well acquainted with cljsjs now, since i assumed, at first, i was using it wrong and spent quite at bit of time going through the source.
it would be great if we could find a way to deprecate things like this with a warning, for example, and actually move to a deps.edn file.
since we expose the compiler through the boot-cljs task, though, we could fix it at that interface.
i can see how someone might not want to introduce breaking changes, but this kind of stuff only causes more pain later.
parts are actively being written by people in javascript, other parts are being written in clojurescript.
but this adds overhead, checkout deps, additional repos, and the like. i'd argue that these are a bit more cohesive than that.
that's what i've done, and it is ok. but it does seem that we should be able to support js files in a cljs project in as convenient as fashion as we can have .java files in a clj project.
send like a good idea to have a well defined api for the js code if those programmers are only doing the js
i think, more likely than not, i'd always use interop. maybe this hypothetical scenario where i want to hand-write some parts of my project in javascript doesn't really exist.
i'm merely identifying reasons i think it could make sense to have .js and .cljs files in the same project together.
html could be one module, css could be another module, my javascript selectors could be a third. but since the same component uses all three of them, that would be madness. they're cohesive, even through they're different languages.
and i think the same applies for some js files; sure, there has to be some kind of interface, but sometimes one that is more lightweight and part of the same project is better.
yeah, i'm grokking that... it almost seems semantically equivalent to the js task i was proposing, in fact.
is it really the jar, or the config/foreign-libs config that is necessary for the compiler to make them work?
which, i presume, takes some part or all of the configuration that goes into deps.cljs.
the file is a way for the jar to add to the compiler option when it's included as a dependency
it might work out of it, the results from the previous debugging i did are useless because they also incorporated the ns+
bug.
i will buy you many beers if you have the bandwidth to fix that soon, otherwise i'll try to tackle it this afternoon.
yeah, you hold the fate of the world in your hands down there. up here we're contemplating more important things, like weed.
(in the interim, i'll be setting up a private wagon where i can share all my extra private jars)
@jumblerg boot-bucket
looks a lot like sync-bucket
task of https://github.com/confetti-clj/confetti
does (page)
actually exist anywhere or is it just magically replaced by boot-hoplon?