This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # announcements (13)
- # asami (4)
- # babashka (47)
- # beginners (22)
- # calva (11)
- # circleci (1)
- # clj-kondo (14)
- # clojure (43)
- # clojure-europe (43)
- # clojure-gamedev (1)
- # clojure-nl (1)
- # clojure-uk (6)
- # clojurescript (13)
- # core-async (5)
- # cursive (8)
- # datomic (20)
- # events (3)
- # fulcro (12)
- # graalvm (1)
- # graphql (4)
- # gratitude (3)
- # java (2)
- # juxt (2)
- # leiningen (12)
- # off-topic (30)
- # pathom (33)
- # pedestal (5)
- # podcasts (1)
- # polylith (14)
- # rdf (2)
- # re-frame (12)
- # reagent (3)
- # releases (2)
- # shadow-cljs (24)
- # spacemacs (13)
- # sql (2)
- # tools-build (16)
Are there any conventions established around sharing polylith components as separate repos? Thinking of using a naming scheme like
Can you elaborate? A Polylith workspace is going to have a configured "top-ns" and all namespaces in that workspace are going to include that.
You can publish a library from a
project in a Polylith workspace and that can be used from any other Clojure projects.
(and you could have the library's api in
projects/<library>/src under "any" namespaces you wanted I think?)
Useful info, thanks! Will bear that in mind as I try sharing a bit of code. With my question I was thinking less about technical details and more about community conventions around e.g. naming, discovery. In other words, if I see a GitHub repo named
clj-poly.foo it's perhaps a hint that I can expect to find it organized according to component conventions, e.g. with a separate
interface.clj and implementation namespace, etc.
Perhaps sharing an individual component in the way I envisaged is not particularly useful, and sharing as a project library has more utility; I am still at the foot of the polylith learning curve. 😄
I think a "component" is something physically in your workspace. Something "shared" is a library and is accessible via a dependency.
A component (and a base) is decoupled from any sort of deployment. A project is what defines how a set of bricks should be assembled for deployment -- for "sharing".
You can already depend on a specific project in a Polylith-based github repo, via a git dep and
:deps/root -- that's how the
:poly alias in a project can be set up (or how
poly itself can be installed as a CLI tool).
Tremendously helpful, thanks a lot!
About @U04V70XH6’s question. Yes, you could have a top namespace
com.my.company and then include another namespace from
projects/src/com.another-ns that delegates to the bricks that live in
com.my.company. In the documentation we just say that we don’t recommend adding functionality under the project’s
src directory, but this could be a useful use-case.
Status update on our Polylith migration -- we're up to 35 components now and climbing (I've declared today "refactor Friday" so I'm slowly pulling apart legacy subprojects and moving code into
projects: 18 interfaces: 34 bases: 6 components: 35
Has there been a change in the way you break them apart since you've started? Any notable conclusion, shifts in approach, or things to keep in mind going in? Any change in perspective?
Not really. Nothing beyond what I blogged about in terms of naming, modularity, and dependencies.