Fork me on GitHub
Slack Archive

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

2022-03-10

Channels

#polylith
<
2022-03-10
>
jeroenvandijk17:03:10

I am wondering if I am doing something wrong. After I make a change in the tests of a component, the test command is running the exact same tests twice. This is just because the component is being used in two projects. In both projects the relevant components used in the test are exactly the same though. Even though it is a simple test, it takes around a minute from the poly shell (startup time?). I’m thinking this could at least be halved by running the test only once. But this goes against the possibility that one of the projects uses a different implementation. I haven’t used this swap feature yet, but I’m paying the price for it. Is there a way to make this scenario more efficient?

jeroenvandijk17:03:10

I found a nice solution after reading the documentation one more time. I can filter for just the project I’m interesting in (at this time): poly test project:<project-name> and it will only run the tests for that brick from the perspective of that project. Perfect 🙂

jeroenvandijk17:03:27

From the documentation I read to keep our fast _brick_ tests fast enough to give us a really fast feedback loop (https://polylith.gitbook.io/poly/workflow/testing). What do you consider really fast? The test command is only fast for me when there are no changes, if some brick is affected, it takes at least half a minute. Enough to make me impatient unfortunately

tengstrand07:08:02

I would say it’s a balance between how confident you want to be and how long you think is a reasonable time to run the tests.

jeroenvandijk19:03:14

Is the Poly project itself still a good example of how to organise the classpath with polylith? I see that deps are defined in the https://github.com/polyfy/polylith/blob/master/deps.edn#L34-L46 whereas I think the https://polylith.gitbook.io/poly/workflow/libraries is saying that the deps should be defined in the components so that they are self-contained

pavlosmelissinos19:03:12

You're conflating two different things > see that deps are defined in the https://github.com/polyfy/polylith/blob/master/deps.edn#L34-L46 some deps that happen to be useful during development > the deps should be defined in the components so that they are self-contained the deps that are used by the components the "main deps.edn" is the deps.edn of the Dev project that the documentation mentions: > Libraries are specified in deps.edn in each component, base, and project > Dev project src ./deps.edn > :aliases > :dev > :extra-deps There's nothing wrong with having some dependencies that are useful during development in the development deps.edn

jeroenvandijk19:03:29

I see your point. Adding some extra deps for development is ok. But I see that it’s not just about extra deps. There is redundancy between the component deps and the deps in the main deps.edn (e.g. zprint, me.raynes/fs, mvxcvi/puget)

jeroenvandijk19:03:31

I wonder if these “examples” need to be updated or if I just have some misunderstandings

tengstrand20:03:00

Both @U2BDZ9JG3 and me use Cursive which doesn’t suport the :local/root syntax correctly. If you use Emacs/Cider or VSCode/Calva, then you don’t have to repeat libraries that are specified in bricks that are specified using the :local/root syntax in ./deps.edn.

jeroenvandijk20:03:06

Thank you, that helps!