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.

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?

Yes.

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

Cool!

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
 :via
 [{:type java.lang.NullPointerException
   :message Cannot invoke "java.lang.CharSequence.length()" because "s" is null
   :at [clojure.string$trim invokeStatic string.clj 238]}]
 :trace
 [[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.