The only reason to use paths in :dev is to workaround a bug in Cursive, and that also means you need to duplicate all the bricks' dependencies in that alias too. Which is terrible. If you use :extra-deps with :local/root instead (as intended), the bricks' deps will work.

There's a long-standing bug open against Cursive to fix this. Your example should do things properly and perhaps just warn people about the problem with Cursive.

https://github.com/cursive-ide/cursive/issues/2554

I use Calva! switched from Cursive because of that bug.

I use local/root well in my company project. It doesn’t work for this project only, so I’m wondering.

You're using paths, not deps, in :dev.

Switch to deps and it should work

you mean this?

This is not working, either.

I can take a look at the repo when I get to work (on my phone right now), but that looks like it should work...

You'd need to switch your profiles too

And the rest-api dep needs to be pulled out to a default profile I think?

Hmm, it's a base in dev but you are depending on projects in the profiles which doesn't seem right?

Hard to read on the phone - will take a better look when I get to my desk. Is there a default sms component? I only see that in the two profile aliases...

No hurry 😁

Please take a look at your convenience.

I created https://github.com/yyna/polylith-example/pull/1 to show what changes I was suggesting and what tests/REPLs work for me. Hope that helps?

Thank you so much for taking time for this. ❤️🙏

I tried the way you suggested. Project tests are executed even though project tests are not specified in deps.edn. When I see the example from the polylith document, it has projects/{name}/test folder in their extra-paths. This is location of the example code. https://github.com/polyfy/polylith/blob/master/examples/doc-example/deps.edn

BTW, it’s so nice that deps.edn has been compacted.

Since we all use Cursive for Polylith projects, the examples followed the Cursive setup by default. What do you think about it @tengstrand ?

One idea is to add a comment block in these config files, showing how to configure using the :local/root syntax.

I think it would be better to show the non-Cursive setup by default and then have the Cursive setup in a comment -- or as a separate, clearly-labeled example. Whilst Cursive is popular, more people use other editors (Emacs, VS Code, vim, etc) which do not have the shortcoming that Cursive has here -- and the docs end up giving mixed messages on, for example, library dependencies in bricks because of this (b/c you shouldn't need to duplicate them into :dev -- that's just an unfortunate workaround for the bug in Cursive). That's the same line of thinking that has nearly all projects showing command-line instructions for macOS/Linux and then a footnote for Windows where the quoting has to be different.

(I think Polylith docs should encourage people to avoid Cursive until that bug is fixed, but that's a separate argument)

My hope was that the Cursive https://github.com/cursive-ide/cursive/issues/2554 would have been solved by now. The other idea is to use Calva in the examples, as described in https://github.com/polyfy/polylith/issues/123 issue.

I mostly try to write tests against the interface because that's the public face of the component that other code will interact with. I may also have some implementation tests if I feel the need to test parts of the implementation logic.

We have a number of components where the interface functions are not pure pass-through -- we have some variadic interface functions that map to a non-variadic implementation function, for example, or multiple interface functions with expressive naming that map to a generic implementation function that is passed one or more arguments that indicate what behavior is needed (our HTTP client component exposes get, post, etc but our implementation has request that takes a method argument).

(and we have a few interface functions that just have the logic inline for... reasons... 🙂 )

Ahh I see. Thanks. Yeah we use some components specifically for schemas and for those we put the schemas directly in the interface.

While we don't do that consistently, testing against the interface would make sure that even if the interface is passthrough, there are no omissions when doing changes like changing parameter order, changing arity etc.

Yeah, that’s been my thinking.