Interessante approccio lightweigth con architettura by convention https://github.com/polyfy/polylith. Uso lāapproccio descritto per interface.clj
, usando core.clj
nello stesso modo, ma i miei componenti sono top-level in github.
qualcuno mi puoā spiegare il percheā di usare interface.clj
e non usare direttamente core.clj
?
probabilmente percheā il nome eā piuā esplicito riguardo allāuso che se ne vuole fare, rispetto a ācoreā che potrebbe contenere qualunque cosa
ah tipo come fare un subset delle funzioni di core che si possono usare? :thinking_face:
percheā poi in interface si usano proprio le funzioni di core
non necessariamente, probabilmente interface potrebbe dipendere da altri namespace e core potrebbe essere relegato a contenere āmainā
giusto giusto š
La cosa che non mi piace molto di avere un unico repo in github con 30 sotto progetti eā il mischiarsi di issues/PRs e CI collegata allāintero progetto. Entrambe i problemi possono essere risolti con un singolo monorepo, quindi immagino si tratti di una preferenza personale alla fine,
link interessante. neanche io sono un fan di monorepo, mi do unāocchiata cosa dicono questi ragazzi lo stesso peroā :)
mi sembra un buon approccio, queste cose sono sempre un po' spaventevoli quando le guardo (yet another framework) ma qui praticamente vedo solo convenzioni e tools attorno
bel link grazie Renzo
Voi dove le mettete le spec? file separato oppure tutto insieme, mi piace vederle in un file ma alle volte e' troppo š
Sto pensando di tenerle le s/def
nel suo file and le s/fdef
in un altro namespace...ma non so...
la definizione della spec in genere la metto nel file che si riferisce a quel concetto (e ha le funzioni che operano su quello). Le spec per le funzioni le definisco inline nelle funzioni utilizzando guardrails
(my 2c)
eh non mi piace cambiare la sintassi di defn
...e' troppo invasivo (IMHO)