Fork me on GitHub

Perhaps a flashback to @jungin.kwon1’s, are there any ways to manage the top-level deps.edn elegantly, without having to copy&paste all dependencies with :dev alias to support various IDEs(like cursive)?


Or is anything being done or discussed regarding this issue? What I find cumbersome is that the shape of repository should depend on tools developers use.


At work, since no one uses Cursive, we have :local/root extra deps for all the bases and components in our workspace level :deps alias (and :extra-paths for the tests stuff to support testing via the :dev project). Our 3rd party library deps are only in bricks' deps.edn files, except for ones we need to supply differently between :dev for the REPL and projects for building artifacts.


Thanks for sharing. So the feature is included in Cursive's 1.12 milestone!


Yes, fingers crossed on that one, but it’s surprisingly tricky.

🙏 1
Gary Berger14:05:51

Might be off topic, but building an interactive CLI app using polylith architecture, Before I go too far into the rabbit hole, Could I reuse the poly shell component as a base interface or is it too implementation specific to poly .


How I understand it so far is that bricks (bases and components) are only for internal use in a workspace.


Anything that's for outside consumption either as an app or a lib will be wrapped in a project


In a recent PR to the poly tool I was asked to change the name of a component so I wouldn't consider those to be part of the "public api" of a poly workspace


mind that I'm not part of the poly team, only a dev in the process of adopting it