Fork me on GitHub
#polylith
<
2022-05-06
>
wagjo12:05:07

Every larger project tends to accumulate a handful of namespaces with small general purpose or utility functions that are used throughout the project. Something like https://github.com/weavejester/medley or https://github.com/ptaoussanis/encore . I was thinking about how to best represent them in terms of polylith abstractions, and it seems they are more close to a 'library' concept, rather then a 'component' one. Having interface for those small functions brings little to no benefit, yet it is useful to have them closer to the project and not publish them as a full fledged versioned library. My idea is to store such namespaces in the 'libraries' directory inside the workspace (e.g. 'libraries/math', 'libraries/coll'), and then refer to the from component or base deps.edn files, e.g. {:deps {foo/math {:local/root "../../libraries/math"}}} Is this in your opinion fine or should I rather meticulously define interface for every small general purpose functions that I'm not ready to publish as a part of a totally separate library?

Hukka13:05:56

We cheat by putting implementations in the interface for our helpers and utils

Hukka13:05:16

So the utils is a separate component, but with just the interface file

Hukka13:05:39

Then again, you could just as well cheat by requiring any non-interface ns too

Norman Kabir13:05:08

Agreed. I've found that its possible to implement methods directly in the interface and add the abstractions later when needed. Clients are unaffected when the implementation is split out.

tengstrand13:05:00

Yes, it’s okay to put implementation code directly in the interface if you think delegating to an implementing namespace is not needed or add any value. If you for example put your util functions in a util component, then an option is to group the different util functions in different sub namespaces (especially if you have many functions).

wagjo13:05:53

Thanks all!

👍 1
Norman Kabir13:05:06

I've been working with three tools that could potentially work together to create a full-stack development environment but have not yet integrated them properly: - https://polylith.gitbook.io/polylith/ - https://kit-clj.github.io/ - https://fierycod.github.io/holy-lambda Each is great but together, they'd be incredible. However, due to some differences in implementation, they're not easy to integrate yet. - Polylith https://github.com/polyfy/polylith/issues/206 src while Kit uses src/clj,src/cljs,src/cljc. - Holy Lambda works with https://github.com/FieryCod/holy-lambda-ring-adapter/blob/master/examples/native/src/example/lambda.clj while Kit is built around https://kit-clj.github.io/docs/integrant.html. I'm curious if anyone else has attempted to tie these together?