This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-16
Channels
- # announcements (2)
- # beginners (50)
- # boot (80)
- # calva (4)
- # cider (58)
- # cljs-dev (11)
- # clojure (140)
- # clojure-brasil (1)
- # clojure-denver (1)
- # clojure-dev (10)
- # clojure-europe (8)
- # clojure-finland (2)
- # clojure-italy (5)
- # clojure-nl (2)
- # clojure-quebec (1)
- # clojure-spec (2)
- # clojure-sweden (4)
- # clojure-uk (94)
- # clojurescript (98)
- # cursive (19)
- # data-science (1)
- # datascript (9)
- # datomic (43)
- # emacs (2)
- # fulcro (29)
- # graphql (41)
- # hoplon (15)
- # jobs (2)
- # kaocha (4)
- # liberator (24)
- # off-topic (9)
- # perun (1)
- # re-frame (11)
- # reagent (17)
- # reitit (8)
- # remote-jobs (2)
- # rum (2)
- # shadow-cljs (24)
- # spacemacs (1)
- # specter (1)
- # tools-deps (21)
@jeroenvandijk how stable has that been?
Is there a boot noop to put into a pipeline when conditionally building it? Like (comp (when (= :env :dev) (draft))
?
@jayzawrotny ok so the boot task is like a double wrapped function
when you create a task you are returning a function that returns a fileset
so to conditionally wrap that you would use a cond->
I do it often, one sec I have demos
Ah right, the middleware so would need to be like (comp (if (= :env :prod) (draft) (noop))
where noop is like (fn [next-handler] (fn [fs] (next-handler fs))
yeah I find the threading macro easy tho
(cond-> (identity)
(= :env :dev) (comp (dev)))
that way I can build up a pipeline of conditional tasks
I could also see a really easy reduce-task
that takes a coll of tasks and reduces them to a pipeline
(comp
(perun/global-metadata)
(perun/markdown :md-exts {:all true})
(perun/draft)
(perun/print-meta)
(perun/slug)
(perun/ttr)
(perun/word-count)
(perun/build-date)
(perun/gravatar :source-key :author-email :target-key :author-gravatar)
(perun/render :renderer ')
(perun/collection :renderer 'eccentric-j.site.index/render :page "index.html")
(perun/tags :renderer 'eccentric-j.site.tags/render)
(perun/paginate :renderer 'eccentric-j.site.paginate/render)
(perun/static :renderer 'eccentric-j.site.about/render :page "about.html")
(perun/sitemap)
(perun/rss :description "Eccentric J's Blog")
(perun/atom-feed)
(sass)
(cljs :optimizations (if (= build-env :production) :advanced :none))
(clean :exclude #{#".git"})
(target :no-clean true)
(notify)))
Is my pipeline thus far, some of those steps are conditional depending on env and some of those steps may take different args depending on the env. Maybe I should manipulate a list then reduce it into a pipeline?I think the correct answer to your question tho is just return an identity
fn as the task, so it returns the previous tasks fileset
ok I see what you are doing, take a look at what I have done here: http://github.com/degree9/meta
yeah we are using it everyday
those tasks use the thread approach, it seems you probably want to breakup the pipeline into smaller sub-tasks
(deftask build
"Build the blog source and output to target/public"
[e build-env BUILD-ENV kw "Environment keyword like :dev or :production"]
(let [prod? (= env :prod)]
(->> [(perun/global-metadata)
(perun/markdown :md-exts {:all true})
(when-not prod? (perun/draft))
(perun/print-meta)
(perun/slug)
(perun/ttr)
(perun/word-count)
(perun/build-date)
(perun/gravatar :source-key :author-email :target-key :author-gravatar)
(perun/render :renderer ')
(perun/collection :renderer 'eccentric-j.site.index/render :page "index.html")
(perun/tags :renderer 'eccentric-j.site.tags/render)
(perun/paginate :renderer 'eccentric-j.site.paginate/render)
(perun/static :renderer 'eccentric-j.site.about/render :page "about.html")
(perun/sitemap)
(perun/rss :description "Eccentric J's Blog")
(perun/atom-feed)
(sass)
(cljs :optimizations (if prod? :advanced :none))
(clean :exclude #{#".git"})
(target :no-clean true)
(notify)]
(keep identity)
(apply comp))))
Going this route, I think this should keep things pretty clean. I didn’t see a natural split in the steps because they all work towards building the blog. Without any of these steps I’m not sure the result would be meaningful.
If it builds ™️
Is there a way to get watch to respond to changes in a target/public directory instead of the resources dir?
@jayzawrotny no, by design
one of the reasons why tasks like watch
can be made simple and reliable is that they only manipulate immutable filesets
The intention was to serve the files compiled to target/public as a website and when those files change run through boot-livereload. Sounds like I need to put those in the build pipeline.
Actually, let me back up. I’m learning boot while developing a static site with http://perun.io. I had a watch task that would build the markdown files, gen the html files, compile the scss and the cljs. But I’m curious if I could set it up to be a bit smarter. Currently if I change a markdown file both the scss and cljs get recompiled.
so each task is responsible for figuring out for itself whether it needs to do any work or not
they diff the new and old filesets and see that no scss files changed, and just pass the cached results from the previous run onward
I see, unfortunately they do slow down the recompile a bit. It’s not the end of the world though.
I don’t see anything that strikes me as diffing https://github.com/Deraen/boot-sass/blob/master/src/deraen/boot_sass.clj
Good point. Also, I think I see the issue. It’s setup to diff the entire fileset which is why it’s always recompiling for me. Does this mean I could create another task to compose a sift with just .scss files with boot-sass to make it more efficient?
Nope, so far just one but if I was using this build system for a bigger site it’s possible.
I don’t think it’s the diffing that’s slow, I’m just saying if I change a markdown file: the fileset this task receives will be different than the previous fileset it diffs against and will recompile