@seancorfield so I actually do have a question. I managed to build my project using the new method. Still in the process of rewriting but I have a question. Is the thinking that the root level "development" deps.edn should be using {:local/root ... to refer to the bricks in its {:aliases {:dev {:extra deps [...]}}} list as well? or does this not work for some reason? Seems once you move the dep definitions to the bricks themselves, it would be nice to not duplicate them anywhere but I might be missing some aspect here

aha, from the migration doc: > Notice that the `development` environment, with its `./deps.edn` file, is not converted to use `:local/root` and the reason is that the `:local/root` definitions will not be picked up by all IDE's as source code. ok will check this with my env

ok take it back, this does still not work in intellij/cursive

It works in most IDE’s but unfortunately not in IDEA/Cursive. I have written an https://github.com/cursive-ide/cursive/issues/2554 about the problem.

did anybody happen to ask clfeming on slack whether there might be workaround to this with cursive?

@seancorfield got it all working but I have one more question. How do you deal with common libs which are shared across all components (say something like logging). I created a separate component with just a deps.edn with the common deps and made the other components depend on it using {:local/root ...} . This way the dependency is there in the component (where it belongs in my view), but you don't have to duplicate it in all components and/or in the root deps.edn and the project deps.edn files. This works but I'm not sure it falls naturally into the poly pattern.

granted, you could state that there are no such libs and if they exist you duplicate them, but for the sake of argument, lets say there are.

@mbjarland So far we haven't felt that the duplication of dependencies is a problem. For logging, which is likely common to (almost) every component, one possibility is just to put it in the workspace deps.edn file under :dev and in each of the projects that you build (as needed). Generally, you're going to have a relatively small and fairly stable number of projects, compared to components.

We've decided to err on the side of explicitness and go ahead and duplicate every library dependency into each of the components's deps.edn files that represent a true usage, because that seems to play better with poly libs etc.

We use antq to detect outdated deps so that catches anywhere we update the lib version in some places and not others -- and poly libs will also show that you have different versions in different places.

I agree with @seancorfield .

ok thank you @seancorfield and @tengstrand . I do hate duplication so we’ll see what I can live with, but seans way or the extra module both seem cleaner to me as the dependencies for a component are declared in the component. Pushing them into the root level deps and the projects makes the components less self contained and less self explanatory which would seem to be a downside to me. Anyway, thank you both for the perspective and pointers. Much appreciated and I’m liking the new poly structure.

Sounds great.