Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-02-22

Channels

#polylith
<
2022-02-22
>
oly15:02:13

Anyone renamed all there interface files ? wondering if there is a simple way to rename in all the files and filenames, decided interface is not a good default given clojure runs on many runtime and it causes issues on javascript runtimes, so thinking of using something like ensemble unless other know of some other tricks for js ?

seancorfield17:02:36

@UU67HFS2X You can set :interface-ns in workspace.edn to use something other than interface in your Polylith setup.

oly08:02:54

yeah I was aware of that, just means I have to go through updating the namespace and files in a lot of components to match unless it can take a vector I guess, which is why I wondered if anyone had done something similar seems the interface conflict will hit anyone working with js as interface is a reserved word

seancorfield17:02:52

I don't know how many folks are using ClojureScript with Polylith but I would have expected someone to have run into the interface/JS issue by now...?

Pieter Koornhof18:02:07

We have 3 cljs apps, but all the code is still tied up in bases. So blissfully unaware of what you are talking about

Oliver Marks19:02:26

yeah i have been splitting out the react components into polylith components in cljc files but when ever hotreload is triggered it give you warnings about interface being renamed to interface$ you can live with it but it is rather annoying, I was doing the same before hand though storing it all in a base

jeroenvandijk16:02:06

I have a component A that depends on another component B. This dependency is declared in the deps.edn of A. When I include A in my project, the poly tool says it’s missing the interface of B (Error 107). Is this correct? Should I always declare all components top-level?

jeroenvandijk17:02:03

I’m guessing swappable implementations don’t work anymore when components depend on each other via deps.edn

Matt Ielusic17:02:38

Yeah. I understand that dependencies between bricks shouldn’t be explicitly declared, so the Polylith tool has a command to calculate them.

Hukka17:02:53

Yes, otherwise the profiles couldn't change the implementation

seancorfield17:02:56

Dependencies between bricks should be in the project deps.edn file, not the bricks' deps.edn files.

seancorfield17:02:10

(and :dev is a project in the workspace-level deps.edn file)

seancorfield17:02:33

Only libraries should be in the bricks' deps.edn files.

seancorfield17:02:37

The "missing" error comes about because poly looks at projects for those cross-brick dependencies and in your case it is missing from :dev and whichever projects depend on A.

seancorfield17:02:54

@U0FT7SRLP Does that make sense?

Matt Ielusic17:02:06

Maybe this is too pedantic, but the project deps.edn doesn’t say “A depends on B,” as much as “this project uses both A and B.”

Hukka17:02:26

Indeed, because deps really is about source code, or implementations, while the components depend on namespaces, or interfaces

jeroenvandijk17:02:08

Thanks all. @U04V70XH6 Yeah it makes sense now. From the error itself I couldn’t figure it out. But by trial and error I started to realize what was going on

seancorfield17:02:58

@U0295UQ75FG Yup. I meant that if project X "depends on" (uses) A in :deps then it must also list B in :deps. Pedantry is important here 🙂