https://polylith.gitbook.io/poly/architecture/workspace#existing-git-repository workspaces is supported by the poly tool.

The polylith repo has several nested workspaces in the https://github.com/polyfy/polylith/tree/master/examples directory.

So one can use this trick with my-git-repo-dir also being a Polylith WS? Will this enable the nested workspaces layout that you described https://clojurians.slack.com/archives/C013B7MQHJQ/p1683290566531419?thread_ts=1683288934.364709&cid=C013B7MQHJQ, with only the difference of all workspaces’ code being Clojure-only for now?

i.e. in the example layout above, both my-repo, backend, and frontend are all Polylith workspaces, the latter two are able to share components with one another and also use my-repo’s “shared” ones — and all this is currently possible, correct?

Will poly tool be mad about root dir(s) or top-ns(s) skews or smth. like that, won’t it?

It's not fully supported to share components between workspaces today, but you can import them as code using :local/root but then the change mechanism will not catch changes, and that is what discussion 301 is also about (not only about adding support for cljs). The idea in the new solution is to be able to share bricks between workspaces, even if they have different top namespaces. My idea is that every workspace can have its own alias, and that we prefix the components that we share from another workspace.

Yeah yeah yeah, that was exactly the concern I wanted to confirm. Thank you, Joakim! Having a native support for shared bricks from the tool would be so much better, indeed!

Yes indeed!

❤️ Polylith and the team (Sean C. included)

@U1G0HH87L one more follow-up question. Whenever you work on this task, will you make it possible for top-level workspace to respect custom top-namespace’s of the nested workspaces? So that the top-level settings do not dictate the lower-level settings.

Yes, each workspace will have their own workspace.edn with their own top namespace configured.

Great! Just for the record, the use case is simple. I would like to have a component which is open-sourced under a different top-level ns, and seeing constant warnings (Warning 205: Non top namespace XXX was found in XXX.) is of no pleasure, of course. If I understand your plans correctly, these warning should also go away if I extract this component into a nested ws of its own, whenever this Polylith feature is implemented.

All bricks within a workspace has to conform to the top namespace specified in that workspce, so in this case you will have to move the brick to a workspace with a matching top namespace, to get rid of that warning.

Yes, I understand this constraint. But the point is, this won’t matter whether that workspace is a separate one or a nested one (hopefully, soon).

Okay, now I understand what you mean. One possible solution could be to add support for turning off this warning.

How is this possible then? In any case, this “brick” will also later need to be divided into parts, and ideally — to become a workspace.

This is so cool. That’s awesome you already have some level of support for nested workspaces. I want to use this for having a fullstack CLJ and CLJS like @U01CC82BJKU and share components between them.