Cool!

I'm blogging about our migration at https://corfield.org

But we already had a fairly good setup with our monorepo: a single REPL for all code that could run for weeks without reloads.

that's really the primary productivitiser™

we've 5 repos right now and it's like nails on a -ing chalkboard whenever we have to work across a repo boundary

The built in test runner that is executed when you run the test command looks into all bricks and finds their test code and calculates all dependencies (libraries and paths) needed to run the tests for each project. This is described in the https://github.com/polyfy/polylith#testing section, under “How tests are executed”.

Thanks. And if the foo interface has multiple implementations in the workspace, how will one be chosen?

I couldn't find that in the section you mentioned

In Polylith, context is defined by projects. In other words, the tests run in a projects context. So let’s say you have project1 that includes foo1 and bar components. You have another project, project2 with foo2, bar and baz components. Let’s say foo1 and foo2 implements the same foo interface. Then, Polylith will run the tests in project1 context with foo1 and bar. Also it will run the tests in project2 context with foo2 bar and baz. We achieve this with using different classloaders so the tests run in the correct context. You can check out how the test-runner is implemented https://github.com/polyfy/polylith/blob/master/components/test-runner/src/polylith/clj/core/test_runner/core.clj.

Even brick tests run in a project's context? https://github.com/polyfy/polylith#test-approaches

Yes.

Thank you, that's very interesting indeed!

It’s like Lego™ bricks, they have input and output points but without connected, they are not meaningful alone. However, you can connect them in different ways as long as connection points match.

Sure, although a brick will probably have some unit tests that aren't dependent on the outside context - I take it those are executed in all contexts the brick is included in?

Yes, but that is also configurable, so that you can choose which bricks to test for a specific project. I recommend you to read the https://github.com/polyfy/polylith#testing section of the documentation, and if something is still unclear, I’m happy to answer your questions!

Thank you again.

Interesting! It feels “on the road” to a Polylith-style codebase, and it’s quite easy to imagine how that source directory structure would map into an equivalent set of Components.

Fulcro RAD has the same kind of domain-based source code organisation. And is the preferred/ideal/encouraged setup for all Fulcro projects.