This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (43)
- # beginners (11)
- # boot (141)
- # cider (48)
- # clojure (82)
- # clojure-canada (1)
- # clojure-dev (1)
- # clojure-norway (20)
- # clojure-russia (6)
- # clojure-uk (12)
- # clojurescript (268)
- # datomic (14)
- # editors (5)
- # euroclojure (5)
- # jobs (2)
- # ldnclj (109)
- # off-topic (7)
- # om (6)
- # other-lisps (3)
- # re-frame (13)
- # reagent (3)
- # sim-testing (5)
- # sydney (1)
martinklepsch: yeah having an API in boot.core is probably a good idea, although we haven't really nailed down exactly what the public api of boot is
@micha: Do you have opinion on what boot-cljs options should be task options and what should be set from .cljs.edn? I'm thinking main ns, init-fns and (implicitly) docroot are set in cljs.edn and rest from task options (optimizations, source-map, compiler-options).
@micha: I'm not sure, I see some mentions that compiler options could be set from cljs.edn
I'm not sure, I don't think it's reasonable to change compiler options during autobuild
First I though options could be merged but I now think it would be simpler to define where different options must be set
Also, would be easy to use lazy-graph to order tasks automatically (user would write the task dependencies)
Maybe, but I also want to minimize anything which could be changed by changes in Cljs
currently boot-cljs only using cljs.build.api, cljs.env (which should be okay though it isn't a api ns) and cljs.analyzer which might break anytime
can't we keep our own sanity by just sticking to something that works until there is a clear path forward?
Well, I'll be using latest cljs but yeah I'm okay using something that works until there is something clearly better
I did check the ordering stuff yesterday and I didn't see way to currently do the same using public api
So once boot-cljs is otherwise cleaned I might take another look at that and see what it would require in cljs end to make it work
but like a proposal that hasn't been in production and proven to be useful will waste a lot of our time in discussion
Yeah it could work both ways, the library would mimick cljs api for old cljs versions and work as template to find new api functions
or not for reloading, but for checking if there are any cljs namespaces which depend on macros on a clj ns
back to cljs.edn, would it be reasonable to remove default cljs.edn and warn user that other tasks can't add their stuff it cljs.edn doesn't exist?
@micha: Perhaps it would be simplest if cljs task always wrote .cljs.edn, in addition to properties already in file, it could write compiler options etc. there for debugging and for other tasks
yeah i really like the idea of haivng a file that describes the parameters of the build in some abstract way
Should there be an API for other tools which need to read/manipulate cljs.edn or should boot-cljs presume that others know how to do that manually?
if filesystem meta can serve the purpose that would be a really elegant solution i think
I doubt there is any dependency issues if there is separate ns (adzerk.boot-cljs.api) which would probably depend only on boot.core
Pff, I would like to finish perun/endophile/pegdown changes but Pegdown developer doesn't seem to be active :S
(https://en.wiktionary.org/wiki/pff#English I did check that pff is valid interjection)
was able to get a script working easily, but noticed dosh and sh don't allow for passthrough of opts to conch. seems like it'd be nice to be able to pass the stdin reader into each process for interactive stuff.
but anyways, you could drive conch more directly through
boot.from.me.raynes.conch, the vendored version of it
possibly, i haven't even used it in anger yet, so I can't say i'm fully informed, but this was the first thing i tried to do with boot and the first issue i hit with it.
it seems like being able to specify opts to conch would give all the extensibility you'd want.
and a dynamic var is fine for that, since it's using futures or synchronous and those values get conveyed.
gtrak: PR gratefully accepted, or if you make an issue describing how it would work we can make it happen