Yes, it looks like you are right. The right behaviour should be that it only considers namespaces inside the components directory as interfaces. I can have a look at this tomorrow and try fix it.

Thanks!

One other thing I tripped over during my refactoring marathon was this NPE:

#error {
 :cause Cannot invoke "Object.toString()" because "s" is null
 :via
 [{:type java.lang.NullPointerException
   :message Cannot invoke "Object.toString()" because "s" is null
   :at [clojure.string$ends_with_QMARK_ invokeStatic string.clj 370]}]
 :trace
 [[clojure.string$ends_with_QMARK_ invokeStatic string.clj 370]
  [clojure.string$ends_with_QMARK_ invoke string.clj 366]
  [polylith.clj.core.deps.project_brick_deps$test_QMARK_ invokeStatic project_brick_deps.clj 80]
  [polylith.clj.core.deps.project_brick_deps$test_QMARK_ invoke project_brick_deps.clj 79]
  [clojure.core$complement$fn__5687 invoke core.clj 1443]
  [clojure.core$filter$fn__5912 invoke core.clj 2821]
  [clojure.lang.LazySeq sval LazySeq.java 42]
  [clojure.lang.LazySeq seq LazySeq.java 51]
  [clojure.lang.RT seq RT.java 535]
  [clojure.core$seq__5420 invokeStatic core.clj 139]
  [clojure.core$filter$fn__5912 invoke core.clj 2813]
  [clojure.lang.LazySeq sval LazySeq.java 42]
  [clojure.lang.LazySeq seq LazySeq.java 51]
  [clojure.lang.RT seq RT.java 535]
  [clojure.core$seq__5420 invokeStatic core.clj 139]
  [clojure.core$sort invokeStatic core.clj 3101]
  [clojure.core$sort_by invokeStatic core.clj 3107]
  [clojure.core$sort_by invokeStatic core.clj 3107]
  [clojure.core$sort_by invoke core.clj 3107]
  [polylith.clj.core.deps.project_brick_deps$source_deps invokeStatic project_brick_deps.clj 127]

I will have a look at these problems today (I’ve been on holiday) and come back when I know more.

@U04V70XH6 I couldn’t reproduced all your problems, but I have tried to fix them anyway. The changes are pushed to the issue-66branch together with other fixes that I was working on. It should fix your 107 error . Try it out to see if you have any remaining problems.

Thanks, I'll update the poly tool to that latest SHA and I'll let you know if I run into any issues on Monday when I'm back at work!

Confirmed that I don't get the 107 error now on code that refers to brick-like nses that aren't Polylith interfaces.

info and test :dev :all both seem to work correctly too.

Sounds great.

Does that code live under the components directory, or somewhere else?

The tool reads components from disk https://github.com/polyfy/polylith/blob/90ca45583036425ccabe932c9517cec34475ba93/components/workspace-clj/src/polylith/clj/core/workspace_clj/components_from_disk.clj#L31 so I guess you now have 23 directories under the components directory?

Right, we have 23 components now, but the ws.messaging.sdk namespace that was referenced in one of those components (actually in a bases entry I think it was) lived under a wsmessaging-sdk legacy subproject: wsmessaging-sdk/src/ws/messaging/sdk.clj which, of course, Polylith doesn't see -- so as far as its concerned, some Polylith code in bases/batch-jobs/src/ws/batch_jobs/messages.clj is trying to reference a brick that doesn't exist (because it's in one of the 40 legacy subprojects). That legacy code has namespaces that start with worldsingles (old code) and ws (newer code) and then I picked ws as the top ns for the Polylith code, not realizing it might "conflict".