Fork me on GitHub

Hi, I recently found out about polylith and just read the docs. It looks attractive, and porting our codebase shouldnt be too much work, since we already structure things in “components” (separate lein projects for things like “db” and “auth” that we connect with checkouts) that approximately follow the interface/implementation approach (except that we have one core.clj and implementation in impl). But I have an important (for us) question: We have quite a lot of cljc code, because our (re-frame built with shadow-cljs) frontend is rather calculation-heavy, and it happens frequently that computation moves from frontend to backend or the other way around. That also means that we very often split out the “interface.clj” into two namespaces: one in .cljc with the real core functionality, and another one with backend-only functionality (like loading from file, etc). So the question: do you see issues in porting all of that to polylith? Will it handle the cljc ok? Will having a re-frame app in there (as a “base”?) work out ok? Anyone worked in these conditions already? Thanks for reading the long question 😉


Hi @U0G4JDMLM! I know of at least one team the put all their front-end code into a base, who said that it worked well for them. But if you ask me, I would prefer to separate the two languages more. The reason is that you can’t mix the cljs base with clj components in a useful way anyway (except if you write all code as cljc , but I don’t know it that is practical/possible). The code in the issue-66 branch will be migrated into master any day, and when that is done (or if you start to use the issue-66 branch), you will get support for having a workspace within a git repo, so that you could have e.g. a clj , cljs and a cljc directory at the top of the repository and then import the cljc code into the clj code using :local/root . Another alternative is to put both cljand cljc code in e.g. a clojure directory and the ClojureScript code into a clojure-script directory and refer to the cljc code from the clojure-script code (I haven’t tested this, but my guess is that it should work). Or to put it another way, if you can mix frontend and backend code using “normal” tools.dep projects in combination with a mono-repo, then it should also be possible to do it with Polylith.


Hi @U1G0HH87L, thank you for the quick response! I think we would rather write all code in cljc for components where it makes some sense. And maybe it’s a cleaner solution to separate the “loading” etc into a separate component, so the algorithmic components stay as pure as possible. I guess it will take some trial and error to get experience on how small components should be for us.


Okay, cool. If you have any more questions or if you find good solutions to this problem, don’t hesitate to contact me/us again.

👍 2

I have pushed a small fix in the dependency calculation that handles the case when a component is only added to the test context. For you that uses the issue-66 branch, e.g. @U04V70XH6, and people that test the migrate command, please check that your workspace still works. The poly tool now also supports putting :mvn/repos in deps.edn files for bricks, which will be picked up by the projects and used by the test command. Can be useful if you have a component like datomic-ions that need its own maven repo.


Also check out the new promptcommand.


Thanks @U1G0HH87L I'll test out the new version tomorrow morning. Is the prompt command the interactive mode?


Just updated and tested @U1G0HH87L -- the new version seems to work well! libs, info, test all work. Love the new prompt command -- thank you!


Ah, I just pressed ^D to exit the prompt mode, which is how you quit most REPLs, and got this:

(! 538)-> clj -M:poly prompt
OpenJDK 64-Bit Server VM warning: Option --illegal-access is deprecated and will be removed in a future release.
clojure$> ^D#error {
 :cause Cannot invoke "java.lang.CharSequence.length()" because "s" is null
 [{:type java.lang.NullPointerException
   :message Cannot invoke "java.lang.CharSequence.length()" because "s" is null
   :at [clojure.string$trim invokeStatic string.clj 238]}]
 [[clojure.string$trim invokeStatic string.clj 238]
  [clojure.string$trim invoke string.clj 234]
  [polylith.clj.core.command.prompt$start_user_prompt invokeStatic prompt.clj 9]
  [polylith.clj.core.command.prompt$start_user_prompt invoke prompt.clj 5]
  [polylith.clj.core.command.core$execute invokeStatic core.clj 72]
  [polylith.clj.core.command.core$execute invoke core.clj 54]
  [polylith.clj.core.command.interface$execute_command invokeStatic interface.clj 5]
  [polylith.clj.core.command.interface$execute_command invoke interface.clj 4]
  [polylith.clj.core.poly_cli.core$_main invokeStatic core.clj 33]
  [polylith.clj.core.poly_cli.core$_main doInvoke core.clj 7]


I found the mistake. I only tested <ctrl>+C, but not <ctrl>+D. Will be pushed when I have more to push later today.


I have pushed a fix so that <ctrl>+D returns without an exception + a formatting fix for the libs command when running in compact mode.


Confirmed fixed! Thank you.

👍 2

Maybe to clarify: I want the re-frame app in the same monorepo and I need src-path based integration with the cljc to have a good dev experience. I’m not expecting the poly tool to actually work on the re-frame app…