Polylith is designed for building applications, not libraries.

The problem with trying to build libraries is shared components: they will end up in multiple libraries but with the same namespaces, so people using your libraries won't be able to control which (transitive) version of those shared components they get.

If each project's library has no overlap -- no common components -- then it could work, but that seems like you might as well keep each one separate instead of using a monorepo.

@U04V70XH6 They might have overlap. I was thinking to have libraries (projects) that depend on common functionality, to list the library (project) as a dependency instead of the underlying component. For the most part you'd want to import the top level library, that includes all the others, but sometimes you'd want only part of the functionality so you import one sub-library. I did have similar concerns to what you mentioned though

Yeah, right now I don't think Polylith is a good fit for libraries since part of the point of a monorepo with shared code is to avoid the "library versioning" issues -- and you have to think about other libraries depending on your libs, not just someone building an app and having a top-level dependency.

I understand