@U1G0HH87L No, that is not needed. -T invocation automatically adds the current directory to the paths. VS Code / Calva / LSP do not complain. That sounds like a bug in Cursive (or at least another deficiency in terms of how it handles deps.edn projects).

Okay. Because the example uses Cursive, I need to add it. If I mention that it’s not needed in the other IDE’s then it’s probably okay to have it in the instruction (otherwise it’s hard to work with the code in Cursive).

When I start my REPL for the monorepo, if I want to work with the build.clj script as well as regular code, I use clj -A:dev:test:build instead of just clj -A:dev:test

See if Cursive works properly with the REPL if you start it like that? Or is this Cursive's static analysis? (have you opened an issue on Cursive's repo for this?)

It’s not the REPL that is the problem, it’s the IDE integration, and it doesn’t help if I select the build alias.

I saw some discussions in #tools-build or #tools-deps where @U0567Q30W was talking about having problems getting Cursive to work properly with "tool" style aliases. Check out the backchat in those channels (or look on Zulip in those topics in the slack-archive stream).

I just don't think you'll get the build.clj stuff to work properly with Cursive at the moment.

My advice: document what works for VS Code/Emacs/etc and perhaps add a > Note: that Cursive users might need to add additional things to deps.edn -- there's already enough of a mess in the Polylith docs because it leads people to "do the wrong thing" just to satisfy Cursive (I was helping another Polylith user recently and they were having problems because the "correct" thing to do in Polylith doesn't match the docs because of the Cursive nonsense).

Yes, it would be good if we could switch over to VSCode/Calva in the examples and instead have a separate section for Cursive users. I’ve started to update the documentation, but I don’t like what I see, so I will add a note instead as you suggest.

The main reason for my strong position on that is that Colin is actively trying to improve the Cursive experience in all these areas because he knows it is sub-par compared to other editors. Polylith's docs should explain "best practice" for everyone -- since the concessions for Cursive will reduce over time. Cursive is consistently about 30% of the Clojure user base so I agree it can't be ignored, but why hamstring the other 70% of users just because the user experience with Cursive is a bit wonky.

It's not like the Cursive concessions are needed for running the poly tool or building artifacts etc. And the REPL-connected experience in Cursive is just fine. This is purely about the static aspect of Cursive's experience.

Yes, good point.

@U029WR2TAV6 We just put them in component-name/resources :man-shrugging:.

Thanks for your answer. Don’t they end up included in the project’s final package this way?

I’m guessing you could to extra-paths in the test alias to avoid that.

*you could add to

{:test {:extra-paths ["test" "test/resources"]
                  :extra-deps  {}}}

Or something like that :man-shrugging:

I guess my question wasn’t clear. I’m trying to understand if there’s a standard directory to place test resources when using Polylith. It looks like it doesn’t. I’m using a test-resources folder with the extra-paths configuration, as you mentioned. Thanks!

No, I don't think there's a standard place for test-only resources.

I think I would probably use test-resources and :extra-paths.