I think that's a terrible idea. I've tried to work with a Clojure workspace that was not at the root of the repo and it was a painful experience (VS Code/Calva), and I think your forced separation of cljs/clj is a bad idea too since that's not how things work in a modern full-stack environment.

I think there's slightly more justification to demand that a single component is either clj+cljc or cljs+cljc but even that is going to force some compromises on shared code where it would be cleaner to separate clj/cljs implementations than force them into cljc with lots of conditionals.

I think that if you're going to support multiple Clojure dialects you also need to consider how cljr might play into this.

I'd be interested in hearing what the minimum organizational requirements would need to be for poly to be able to successfully consume projects that included both cljs and clj (and, hopefully, cljr in the future). I understand how enforcing that at the workspace level is probably the "easiest" for poly but even a single project could be a full-stack app and need to compile cljs -> js and then build an uberjar containing clj (backend) that serves the (now-js) frontend.

Seconded @U04V70XH6's comments on the Github discussion thread.

I replied in the GitHub discussion too.

@U1G0HH87L That's very interesting... Being able to declare a workspace with :dir "." essentially makes it a virtual workspace that overlays the primary workspace -- and the repo root would still be the root of both workspaces! That alleviates my main objection to @U2BDZ9JG3’s original post -- although I'll still express concern about any arbitrary partitioning of code that is required (if such is required) 🙂

(and, just to be clear, the whole "multiple workspaces declared in workspace.edn" thing is new functionality being proposed, right?)

Yes, it’s just a design that we propose, where we try to solve all the use cases that arise when mixing languages.

I think workspaces do not necessarily need to live at the same level. One workspace can nest another one. At the root, there could be the main workspace, and inside it, we could have a frontend directory that has the sub-workspace.

I think this was a primary concern for you, @U04V70XH6, in terms of IDE support.