I'm working with version 0.3.0 which supports ClojureScript. Now I'm thinking of introducing a new column "dialect" in the info table (example taken from the https://github.com/furkan3ayraktar/clojure-polylith-realworld-example-app/tree/cljs-frontend?tab=readme-ov-file), e.g.:
interface brick dialect be fe dev
------------------------------- -------- ---
article article c-- st- --- st-
article-ui article-ui --s --- s-- s--
auth-ui auth-ui --s --- s-- s--
comment comment c-- st- --- st-
core-ui core-ui --s --- s-- s--
database database c-- s-- --- s--
env env c-- s-- --- s--
home-ui home-ui --s --- s-- s--
log log c-- s-- --- s--
profile profile c-- st- --- st-
shared shared -o- s-- s-- s--
shared-ui shared-ui --s --- s-- s--
spec spec -o- s-- s-- s--
tag tag c-- st- --- st-
user user c-- st- --- st-
web-ui web-ui --s --- st- st-
- rest-api c-- st- --- st-
- web-app --s --- st- st-
I came up with the following letters for each source code type: c = clj, o = cljc, s = cljs. Please provide input on whether you think this is a good idea or not, and whether c/o/s is a good choice.my only thought is what about future dialects ? or even current less well known ones might mean expanding to include more columns
Adding support for extra dialects -- that Polylith actually understands and handles in a specific way -- would be "a big deal" so I think it's okay if additional columns need to be added in some theoretical future...?
Yes, that would be a big deal, and if that happens we add another letter for that dialect.
I'm good with either cos or jcs. I tend to think of them in terms of position. clojure - something in the middle that can be both(cljc) - clojurescript
Here are two examples of how the new dialect column could look. My curent idea is to show it only if :dialect is provided to the info command, similar to :loc. In the polylith workspace, there is no need to show it since all files are .clj . In the realworld workspace, however, which contains a mix of .clj, .cljc, and .cljs it makes much more sense. I'm not sure whether this should also be configurable for users who always want the column to appear, so they don't have to provide :dialect every time. In the first projects table, the dialect column shows the dialects for the projects themselves and for all included bricks.
I think only showing it when users specify :dialect is a reasonable first step -- less disruptive for existing users, mixed language users can opt-in -- then you can gather feedback about perhaps enabling it automatically for projects with more than one dialect?
Yes, I had that idea as well! But since some users may mix clj and cljc , there might be other needs too. Still, as you say, this could be a good starting point.
What does o stand for in your mind? If the values are exclusive (which these seem to be), why have three slots? Only one at a time would ever have a value.
We support having clj, cljc, and cljs code in a single component. In that case, it would be marked as cos. cljc is not a dialect, so maybe "type" would be better name for the header?
The idea is to represent each type—clj/cljc/clj by a single letter. The o is taken from the second letter in common. This is the best I’ve come up with so far.
Another alternative is to use `jcs`, where j = clj, c = common, and s = cljs. I’m not sure this is any better than `cos`, but if anyone has a good suggestion, please share!
The second question is whether we should add this extra column to the info command. I’d like to hear what others think.
Ah, I'd forgotten a component could have multiple "dialects" -- makes sense to have 3 slots now!
I think I'd lean to using the last letter of each dialect -- jcs -- as being more consistent than cos.