This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-12-07
Channels
- # adventofcode (94)
- # babashka (29)
- # babashka-sci-dev (2)
- # beginners (103)
- # calva (15)
- # cider (17)
- # clj-kondo (62)
- # cljsrn (24)
- # clojars (13)
- # clojure (97)
- # clojure-belgium (3)
- # clojure-berlin (3)
- # clojure-czech (1)
- # clojure-europe (68)
- # clojure-nl (1)
- # clojure-norway (3)
- # clojure-seattle (3)
- # clojure-uk (1)
- # clojurescript (7)
- # community-development (29)
- # conjure (2)
- # cursive (14)
- # data-science (15)
- # emacs (3)
- # graphql (10)
- # gratitude (1)
- # holy-lambda (32)
- # hoplon (21)
- # hyperfiddle (2)
- # jobs (2)
- # joyride (36)
- # lsp (4)
- # meander (13)
- # off-topic (203)
- # pathom (3)
- # polylith (6)
- # re-frame (4)
- # reagent (1)
- # reitit (28)
- # releases (1)
- # shadow-cljs (16)
- # slack-help (2)
- # sql (27)
- # vim (2)
Hello, I'm very interested in the Polylith approach. How is the structure usable with some framework like kit or luminous? Do you also hosted normal javascript frontends with it? Like an SPA and a JSON api?
Kit and Luminus aren't really frameworks (in the traditional sense) -- they are "curated collections of libraries" in a project template, so there's no reason why you can't use Polylith for your code while still using those libraries -- but they are opinionated templates so their default organization of code looks nothing like Polylith. I think for full-stack apps, people are putting their front end in one base and their primary JSON API in another base, with a project for each to describe any "build" process needed.
Just updated our CI process to use poly ws get:changes:changed-or-affected-projects since:release skip:dev color-mode:none
so we can build and deploy only the artifacts that actually need it, to cut our build times (since we otherwise build 20 artifacts!). build.clj
code in ๐งต
(defn- changed-projects
"Produce the list of projects that need building.
`since` should be `:before-tag` or `:after-tag`"
[since]
(let [basis (b/create-basis {:aliases [:poly]})
combined (t/combine-aliases basis [:poly])
cmds (b/java-command
{:basis basis
:java-cmd (find-java)
:java-opts (:jvm-opts combined)
:main 'clojure.main
:main-args (into (:main-opts combined)
["ws"
"get:changes:changed-or-affected-projects"
(str "since:"
(case since
:before-tag "release"
:after-tag "previous-release"))
"skip:dev"
"color-mode:none"])})
{:keys [exit out err]}
(b/process (assoc cmds :out :capture))]
(when (seq err) (println err))
(if (zero? exit)
(edn/read-string out)
(throw (ex-info "Unable to determine changed projects"
{:exit exit :out :out})))))
and then
(defn build-all-uberjars
"Build uberjars for all changed artifacts."
[params]
(let [projects (-> (changed-projects (get params :since :before-tag))
(set)
(set/difference (set billing-build-artifacts)))]
(uberjars (assoc params :projects projects))))
(defn upload-all-uberjars
"Upload 'all' artifacts to staging."
[params]
(let [projects (-> (changed-projects (get params :since :before-tag))
(set)
(set/difference (set billing-build-artifacts)))]
(uploads (assoc params :projects projects))))
The conditional is so we can get the right answer both before and after tagging the release (which we do after testing but before building, so that the release tag is available to our build process that bakes the tag into our uberjars).We haven't migrated our three billing-related projects to Polylith yet, hence the set/difference
stuff.
Building and deploying all our projects can take ~15 minutes. Building just one takes 1-2 minutes (including running that changed-projects
command twice). So it shaves quite a bit of time off CI.
A blog post will be coming about all this "soon"...