Curious, are there OSS examples of Components that I might want to add to a real-world application? Here are some examples for Rails Engines (another modular mechanism) https://www.toptal.com/ruby-on-rails/rails-engines-in-the-wild-real-world-examples-of-rails-engines-in-action (I do realise that requirements can vary wildly per-app, making a generic Component harder to accomplish and less likely to 'just work' for everyone... that hasn't stopped those Rails engines from being useful)

@vemv Why wouldn't you just depend on a regular library? components feel like internal architecture to me, not a plugin mechanism.

A forum or CMS would feel odd to distribute under the 'lib' paradigm

An interesting precedent is https://github.com/magnars/prone which is a piece of jvm clojure middleware with its own assets (clojurescript)

How would such a thing be packaged for use in another project? Our model for dependencies is external: either an actual JAR on Maven/Clojars or a git dependency or -- if you've manually downloaded it -- a local/root dep. But to use a component you'd actually have to copy it into your own project... which feels like a huge step backwards.

(I previously worked in a tech that expected you to just download blobs of source code into your project -- it was ... primitive)

> But to use a component you'd actually have to copy it into your own project That might by poly-specific (or even not an actual limitation? everything is hackable)

It would be a pretty severe limitation in fact; as it would force one to use monorepos. What if I have to integrate git repos outside of my control? Orgs can be complex

A Polylith project can easily use external deps -- JARs, git, even local/root deps -- so I'm not sure why you're fixated on components.

Heck, a Polylith project can even have projects that essentially just bundle up an artifact that contains a single components' code -- but it would look just like any other 3rd party dependency.

(I've actually toyed with the idea of pulling a couple of my OSS projects together into a single Polylith workspace to streamline reuse and make developing and testing things easier -- but building artifacts would still produce the same "things" as they do in separate projects)

> I'm not sure why you're fixated on components. The link in my OP demonstrates real-world examples of reusable software that people use/appreciate It's a model I'm interested in - not libs, not middleware, not a Docker image

When you depend on a Polylith project as a git dep, you depend on the projects portion:

io.github.polyfy/polylith
                      {#_#_:git/tag   "v0.2.0-alpha11"
                       :git/sha   "6e9fd05220f4d4a651faae9148582fb8c90ff1d0"
                       :deps/root "projects/poly"}

Re: prone -- nothing is stopping you producing projects that offer middleware, but that's not what components are.

Sure, it was an example of distributing something 'bigger than a lib'

(a lot of middleware -- for lein or nREPL or ring -- is distributed as libraries today)

Yes that's another one, one would decouple components from libraries. One would be a superset of the other Another example that comes to mind is Lein plugins... nowadays normally they're lib-first, with a Lein plugin offered on top of that