Deployables will still live in projects. Then our idea is to allow having several workspaces live at the root of the repository, e.g.:

my-repo
  backend
    components
      component1
    bases
    projects
      project1
  frontend
    components
    bases
    projects
      project2
  root.edn

Oh thanks that clears it up for me. At least until I start trying to actually hammer this out. We currently have a base that serves static http files, and our cljs projects use that base to serve the compiled clojurescript and other resources. In this new model, we will have 1 frontend base per clojurescript build, which uses our "static http server" from the backend components to serve them.

Thinking about it a little more, it makes sense to me that the "frontend" projects ultimately just create a set of static resources. Then, there will be a backend project which bundles up the frontend static resources to serve

Does the suggested structure feel natural to you? Would you split up the frontend and backend into two separate workspaces, as we suggest?

It is all still percolating up in my head but I might try it all with just one workspace as a first pass. The important insight I think I have just achieved is that your clojurescript projects should probably just "build" a set of static resources. Serving them is of course the responsibility of some clojure project. You can probably just have a single "static http server" project and deploy multiple instances of it with your clojurescript project dirs mounted to it

Single workspace vs multiple workspaces is likely just a function of developer ergonomics which I am definitely not qualified to comment on at the moment lol

As a point of reference, we already have some unusual polylith projects that don't use Clojure code. They still just sit inside the same workspace. Some, such as our Docker base images, don't even have any code at all besides a docker file. So, we may be abusing the system already

Ha ha! Feel free to "abuse", as long as it solves your problems! The reason for keeping clj and cljs code separated, is to simplify the output of some commands, like the deps command (clj and cljs code can't depend on each other anyway).

Really looking forward to when the poly tool will support cljs fully, so we can divide our repo into proper frontend and backend workspaces! Currently just fails utterly, eg in furkan's very nice polylith-multi-ws-experiment lib 😄 Would be good to have some more clarity around where to place the "shared" files (`cljc`), but maybe there simply is no obvious place (a separate workspace sounds tedious) and it should just belong in the backend as you've suggested before @U1G0HH87L – but that does tickle the perfectionist nerve somewhat… 🙂

If you decide to let cljc code live in the backend, then you can have some level of separation by letting the cljc code live in src/cljc and clj in src/clj within each brick.

Yeah maybe. How are things coming along with the cljs additions otherwise? 🙂

are you building the notebooks and deploying them somewhere, or are they mostly developer documentation? if it is mostly for development, I would place them in the development folder unless they logically fell into a specific component

I'm just getting started, but I am thinking it will be mostly developer documentation. We end up having very large comment blocks in each of our components that are poor man versions of a clerk notebook. We often jack-in to a specific component to develop in isolation as well, so I could be persuaded to keep them in the components . When giving it a try, I followed the tutorial to launch Clerk on localhost:7777 from a "launch.clj" namespace. Then within that call clerk-show! on the specific notebooks within the component. It feels a bit janky, and that's why I am reaching out to see if you guys have some better ideas.

I have been putting them in development inside a folder called notebooks, mainly so you have access to all components and bases. but also curious what others do