This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-14
Channels
- # beginners (19)
- # boot (11)
- # cider (59)
- # cljs-dev (292)
- # cljsrn (2)
- # clojure (121)
- # clojure-brasil (19)
- # clojure-canada (2)
- # clojure-france (2)
- # clojure-italy (57)
- # clojure-spec (54)
- # clojure-uk (20)
- # clojurescript (83)
- # core-async (20)
- # cursive (5)
- # datascript (2)
- # datomic (10)
- # duct (25)
- # editors (4)
- # emacs (2)
- # fulcro (5)
- # funcool (1)
- # graphql (2)
- # immutant (8)
- # java (1)
- # jobs (4)
- # jvm (1)
- # keechma (5)
- # luminus (10)
- # off-topic (113)
- # om (36)
- # onyx (11)
- # parinfer (55)
- # pedestal (7)
- # protorepl (28)
- # re-frame (25)
- # reagent (6)
- # ring-swagger (1)
- # shadow-cljs (113)
- # spacemacs (1)
- # specter (23)
- # unrepl (8)
- # yada (8)
yeah it was that before, if people have strong opinions about the flags - should speak up sooner rather than later
we can remove all the scripts from the Quick Start and when Alex Miller gets around to validating the Windows clj
tool, I think we can replace the whole Dependencies section of the Quick Start with instructions for deps.edn
and drop the Lein & Maven stuff (probably move them elsewhere for reference)
I like -O
just because it reminds me of gcc, but I don't have strong opinions 😄
@richiardiandrea CLJS-2492, I don’t know about that change
@dnolen CLJS-2493
@richiardiandrea thanks applied
@dnolen the thing of CLJS-2492 is that I need a way to sync the two right?
so either I do it when the source maps are "saved" in :source-maps
or before they are consumed
it seems there is a mismatch in the two when using them from self-host
yep so what I am saying is that when I get
from :source-maps
I see the keys of my mapped stuff under something that has _
so maybe the thing that writes in :source-maps
has a problem
while I was fixing the "reading" side
needs more investigation
ok, will try that
will add comments to CLJS-2492 if I find something else, thanks!
Cool. The -O
matches Planck's similar flag:
-O x, --optimizations x Closure compiler level applied to source loaded
from namespaces: none, whitespace, or simple.
allowing more than one watch -w
path would be nice, but that can be added later without breaking things
Just thinking out loud (not seriously suggesting this): Given that if you have ClojureScript in deps.edn
you can now do things as simply as
clojure -m cljs.main <-m foo.core or other options>
it is tempting to have a cljs
variant of clj
that does 2 things:
1) Uses a "base" deps.edn that includes a shipping ClojureScript dep (perhaps doing this via automatically supplying an alias?)
2) Instead of specifying clojure.main
, specify cljs.main
With this, the idea would be that users could still specify a different ClojureScript dep in their own deps.edn
if needed, and in the end it would work essentially like clj
but be for ClojureScript.
All of the above is temptingly close now; that's why pondering it. 🙂it’s something to think about yes, but need to stew on it. Overall I think this is a pretty huge step forward for ease of use
being able to write a one liner to get a CLJS git dep and try something out is really sweet
@bhauman nice idea about multiple -w
, would be trivial to add, we probably want a --preload
or -p
option. Currently we’re not really overlapping much between --compile
and --repl
--main
options. Probably best to keep it that way.
@mfikes a cljs tool would need to pass through all the clj args (-Sdeps etc), is that what you are thinking?
Yes, in other words, replace clojure.main
with cljs.main
and ensure the ClojureScript dep is available.
The pattern is about to be:
clj -m cljs.main (whatever you want)
a small step to
cljs (whatever you want)
We'll get a huge improvement in the Quick Start instructions soon. And if the above were done, they would get one tiny bit simpler.
@r0man I took at look at your patch, I think you cannot elide orphans like that - otherwise it seems fine, I guess I just missed when I did it originally since all the other support for it is already there.
Hi david, I think you had the same thing in place, but removed it again in this commit: f5cd5f902e96aef3861bb72af483779305e59fd6
Regarding the orphans, why do you think they are needed? With orphans included I got a lot of stuff in my cljs-base that I don't really want. Files on the classpath, like test files. And other thing from a checkouts directory. Really a lot! 🙂
The problem back then was that the compiler didn't pick up the main entries from the modules. Because I didn't require them. They should of course be added to the build. But anything else not required?
for example you build your project directory (i.e. (build "src" …)
) but you have files that are never required by your main ns
so my recommendation is to decrease the scope of the patch, and instead fix your build so all these other inputs are not getting sucked in
we do not randomly load things from classpath as compiler inputs, this is something you have configured
ok, but one more question. yesterday you mentioned that I do need to require files I want to have in my build. so far so good. but do you have an example of an orphan I actually want in my build, even though I don't require it?
if you don’t use :main
everything under (build source ...)
will be in the compiled thing
FWIW :modules
with their :entries
are basically a set of :main
namespaces so you can definitely remove "orphans" just like :main
@r0man first patch looks fine - if people complain a lot about the behavior we can go change this later
I really like how cljs.main is providing a much clearer understanding of the various configuration values, much, much better than the conflated meaning of :source-paths
in cljsbuild which means watch-paths, compile-paths, add-to-classpath
@bhauman yeah, and for beginners you could probably go a very long way before you ever start writing out compiler options EDN manually
@r0man I haven't dug into it yet, but there might be a legitimate test failure from the last commit https://travis-ci.org/mfikes/clojurescript/builds/341441134
It seems to be rooted in the fact that
bin/cljsc src/test/self/self_parity "{:optimizations :none :output-to \"builds/out-self-parity/main.js\" :output-dir \"builds/out-self-parity\" :main self-parity.test :target :nodejs}"
terminates quickly without doing anythingI also removed the ensure-cljs-base. this is then basically what you had in another commit
@dnolen I don't think so. you didn't do this in your original commit. and I think this is already done in ensure-module-opts
@dnolen Regarding those orphans again. I was hunting for an orphan called DA39A3E.js (an empty file that breaks my advanced build) the last hour or so. I was looking in all my jar files but couldn't find it. Now that @mfikes pointed out the failing test I was looking into the builds/out-self-parity directory and see files like AEF573C.js and 3FABB9D.js. Do you know what they are doing, and why do they have those funny names?
@mfikes I will check the tests as the only commit regarding self-host is mine
Oh ok I am reading the above :)
@richiardiandrea Right. Your commit was good. See https://github.com/mfikes/clojurescript/commits/master
I like the new cli stuff a lot a lot, just one thing that can be made easier for editors would be to add the .edn
extension to the option file so that in case you need manual editing you get coloring. Minor I know, but advanced user will manually change the final 😸
Also I like the idea of having deps.edn
+ other conf file for the tool you use. I am using serverless-cljs-plugin
now and I also have a serverless-lumo.edn
in there for lumo compiler options
Awesome
OK it does seem that this is different than clojure.main in that you have to explicitly say you want a repl
in this case clj -m cljs.main -t nashorn
it just bails when my expectation from clojure.main is that it would start a repl
A couple thoughts - other REPLs probably want to arg process - need a standard way to print docs for those
btw, with the new main opts support in clj
, you can create an alias :aliases {:cljs {:main-opts ["-m" "cljs.main"]}}
in your ~/.clojure/deps.edn so it’s available on all projects, then use it and append extra opts at the command line clj -A:cljs -t nashorn
Cool stuff
David, so this was breaking my advanced build: https://dev.clojure.org/jira/browse/CLJS-2522 not the empty file
and your suggesting supplying arg modifications? hmmm this could be a function that operates on the final args?
basically put the current dispatch values into two atoms - one for inits the other for mains
and after that I will look at defaults, and see if I can align with the cljs defaults
I’m working on something that’s pretty flexible, off to Clojure SYNC but this is a good plane hack :)
@bhauman hrm besides arg processing it seems like you also need a way to take over main or compile cases
@r0man your patch probably needs more explanation, I’m curious why this specifically is needed in the modules case
@dnolen I believe you are correct, am I right in thinking that that is better served by composing over cljs.main with a figwheel.main?
@bhauman checkout master, if REPL options contains :cljs.cli/compile
or :cljs.cli/main
fns those will take over the default
@dnolen write-javascript should return something that implements IJavaScript, right? The JavaScriptFile record does this, a plain map not.
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1809
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L412
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L443
@dnolen can you explain in which cases which of those types are used? I think I got a bit confused by this.
@dnolen I think this would also mean I also need to define js-source-file then for maps. that's the next thing I get an exception.
and I think since I can't define a multimethod on clojure.lang.IPersistentMap I need to define them on both PersistentArrayMap and PersistentHashMap, right?
where in module processing is this actually failing - I thought I handled a similar problem when I did this the first time?
@dnolen here: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1192
well, when I looked at the class of the sources
that are passed to build-modules, all of them where JavaScriptFile. just 2 of them not, which were foreign deps I think.
so you think we should convert all maps at the top of the function to javascript files?
I don't mind. I just thought passing javascript file types around is the correct approach, and the 2 cases that broke were actully bugs.
should I add an extra check for instance? JavaScriptFile
and don't convert them (since records are also map?s) as well?
I got it working with figwheel and rebel readline, as rebel readline is a :read repl opt
@bhauman about to drop a big enhancement - the surface is the same - but you can add options to hearts delight and take over --compile
& --main