There’s a bit of doc at the end of this bit talking about that: https://cursive-ide.com/userguide/deps.html#working-with-multi-module-projects

They’ll be automatically added if they’re required using :local/root

Nice, for a simple version of that that doesn’t require a plugin, there’s also Quick Lists: https://www.jetbrains.com/help/idea/customize-actions-menus-and-toolbars.html#

Hmm, this is tricky. With Deps, test code isn’t transitive, because aliases aren’t.

So Cursive is technically doing the right thing, because that code wouldn’t be available to your project running outside of Cursive either. Whether that’s a useful thing to enforce is another question.

The best solution I can think of would be to have a test-support module containing the shared test code in a src directory, and then depend on that from both modules. You could ask over in #tools-deps if there are any better solutions.

is there any reason why adding the code to extra-paths shouldn't work?

Don’t you get an error when doing that that modules can’t share source paths?

I do get an error about that when I try to do it via intellij's module editor, yeah

I’m pretty sure you should, because they can’t 🙂

Are you refreshing your project after updating your deps.edn?

I was adding that into my deps.edn from the top level project, so that the module actually does include that source path in it

yep, I'm refreshing my project after updating the deps.edn

Hmm. IntelliJ should complain about that, because I’m pretty sure that’s not allowed.

I’m not sure what the best solution is here, honestly. It’s a deps limitation (can’t easily share test code) mixed with an IntelliJ one (can’t have the same source in two modules). Is factoring the shared test code out into a third module an option?

file structure here: API (deps.edn): - src - test - project1 (deps.edn) - src - test - project2 (deps.edn) the entire project here, our monolithic API, is a single project. Some components of it are used in other projects as libraries, which is why it's broken out

realistically, the tests in all of the subprojects are just parts of the entire main project. I'd be perfectly happy to have the entire thing treated as a single project in intellij, but we do have the dependencies defined throughout the various subprojects

so "shared test code" in this case just means tests in various sub-folders...which happen to have their own deps.edn

I suppose that we can break out the tests into only the top level, instead of keeping them organized with the libraries, but it's going to annoy the rest of my team that we're restructuring our folder to workaround limitations in intellij/cursive, when they don't have these issues in emacs/cider. Also, I'm fairly confident that I had worked around this bug previously using the :extra-paths hack I mentioned earlier. But, that might've broken when upgrading intellij at some point?

granted, just highlighting the whole file and sending that whole thing to the repl is also a valid work around

which might be a "fix" that could be implemented in cursive? When a file isn't part of the module the repl was created in, just send the entire contents of the file to the repl instead?

doesn't fix the test integration though 😞

> When a file isn’t part of the module the repl was created in, just send the entire contents of the file to the repl instead? The problem with that is that this is the actually useful validation. I often have multiple REPLs open serving different functions, and I’ve been saved from loading code into the wrong REPL multiple times by that check.

@U0567Q30W, I figured out why my original approach (just manually adding the test folder explicitly under :extra-paths in an alias) wasn't working. Despite having the global setting Aliases to enable by default set to dev,test, dev wasn't being loaded as an alias for the project. I manually checked the box for dev in the aliases in the Clojure deps pane for the project and now I can load code & run tests in subproject just fine.

I've no idea why it stopped loading that alias for my project. Doesn't seem to be loading dev alias for any of my projects by default, now that I'm looking at it closer

@U236LQYB0 Oh interesting, thanks for that. I’m still not sure why IntelliJ doesn’t complain about the duplicated content roots, but I’m glad it works!

The not selecting dev thing is weird though, I’ll take a look and see if I can see anything going on there.