The path “components/schema-fixture” is incorrect, should be “../../components/schema-fixture” in projects/usermanager/deps.edn
(it should show a warning for non existing path, will fix that). After that change, it works for me.
Nice spotted. I have pushed version: 0.2.0-alpha10.issue66.02: 500c31e95f88a80036b74c9b20712122bbf25a34
Re: schema fixture -- I must have committed the wrong version, sorry. I was experimenting trying to get past another issue, going back and forth between my local version of Polylith, your latest version, and the earlier version on issue-66. Will update to that latest SHA and retest. Thank you!
Yup, confirmed: everything looks good at this point!
Very nice to see the src/test libs called out separately.
I've now tagged the usermanager as stable and a v1.0.0 release 🙂
Nice, well don!
If you want, you could also update the screenshot with the latest output from the libs command, to get the two columns per project (not super important maybe).
But the info command output is also slightly wrong (for the schema-fixture component).
You can make another change in the doc also, from “`clojure -M:poly test` (optionally with `:dev`).” to “`clojure -M:poly test` (optionally with `:project`). By default, only the brick tests are executed, but :project
will also include the project tests. We normally don’t run tests for the development project (by including :dev
, except maybe in the beginning of a codebase before we have created our first project.
Ah, right.
And, yes, tomorrow I'll update the screenshot when I'm on my big desktop.
I guess you can replace what comes after “You can run all the tests via Polylith’s `poly` tool:” too, and change to
clojure -M:poly test :project
+ replace :dev
to :project
in the text that follows.It now says:
* You can run all the tests with `clojure -M:poly test :all :dev`, or just tests for things changed since the last stable tag with `clojure -M:poly test` (optionally with `:project`).
I like that :dev
(or :all :dev
) will run tests for components that are not yet used by projects, perhaps as folks extend the app or add their own.
They can always read all of your Polylith documentation for more details.
That will be a good change of the text.
The repository turned out really well by the way! 🙂
How about this:
* You can run tests for code that has changed since the last stable tag with `clojure -M:poly test` (optionally with `:project` to also run project tests). You can run the entire suite of tests with `clojure -M:poly test :all :dev`.
Yeah, I think that while the Polylith version may look a lot more complicated, all of the individual components are much simpler and easier to understand.
Screenshot updated too (back on my big desktop).
I’m glad you say so. That’s my experience also, that it helps you reason about the code. Instead of having just src
, test
and resources
at the top level for the whole codebase, each “concept” can have their own directories, which keeps things smaller and more cohesive.
The “top-level” of our monorepo at work:
activator login wsadmin-auth
affiliate lowlevel wsadmin-screening
api migration wsbilling-admin
auth newrelic wsbilling-core
build presence wsbilling-member
cfml preview wsbilling-rebill
cfml-admin redis wsbilling-sdk
cfml-affiliate src wsbilling-test
classes system wsmessaging
compile.clj web wsmessaging-core
crud-form worldsingles wsmessaging-sdk
datamapper worldsingles-test wsphotoqueue
deps.edn worldsingles-web wsseogeo
environment wsadmin
🙂Each of those has src
, resources
, and test
and they each have their own deps.edn
. There’s also the root deps.edn
which is similar to Polylith’s.
We just don’t have a) the top-level separation into bases
, components
, and projects
and b) we don’t distinguish between bases and projects. activator
and api
are both. So are auth
, system
, wsadmin
, wsbilling-admin
, and a few others.
And c) we don’t have a standardized namespace structure in each of those. Yet.
Hi! I take a look to polylith and I like it! I’m wondering if it’s possible to manage the UI too (with cljs of course) in the same `workspace` ?The Clojure(Script) ecosystem is awesome and typicaly we can share schema (spec, malli) between front and back. Is this possible?
▾ workspace
▾ components
▾ mycomponent
▾ src
interface.clj
core.clj
ui.cljs
▸ test
▸ resources
And add a new entry in the projects
folder.Here’s my example repo, including Clojure, ClojureScript and cljc
code as the glue in between (I’ll also post a link to my blog post about it in the #news-and-articles channel)
https://github.com/DavidVujic/polylith-experiments
Nice!
ooooh well done @david043 !
Thank you @jean.boudet11!
Juste a little note. When a component
has Clojure (clj) code and ClojureScript (cljs) it’s maybe good to separate into a ui
namespace (or another name) like this:
▾ workspace
▾ components
▾ mycomponent
▾ src
interface.clj
core.clj
▾ ui
interface.cljs
▸ test
▸ resources
I don’t no if it’s a good or bad pattern but this allow to separate interface.clj
and interface.cljs
Good idea!
I guess it depends, maybe they could be two separate components?
You are mixing languages within the same component here + that it contains two separate interfaces also. My gut feeling says that the two “components” should be separated and live in two separate src
directories . The UI code could either live in its own src
directory, or together with other ui code, optionally in a separate base
which another team here did (we haven’t). But with that said, feel free to experiment @jean.boudet11!
Hi @jean.boudet11! I am currently working on a solution like that and am writing a blog post with an example code repo - but took a break for the easter holiday today 😄
I think I will have something to share tomorrow or maybe monday.
Priority to the easter chase 😉