tools-deps? https://gitlab.com/clojurians-zulip/feeds/-/blob/master/.gitlab-ci.yml

With deps, yes

ah! you solved the same problem I'm solving

why oh why can't the m2 local repo be configured as an external environment variable

and thus, we have to resort to messing with the deps.edn during buildtime

You can pass the local m2 with -S flag

Why do you have lots of code in your tests? Data literals or something else?

a lot of different cases ... there are about a dozen functions in the api ns, and each of those requires testing with a few different broad classes of input, and sometimes multiple cases within each class of input ... there is perhaps some scope for abstracting the test code some more, but i have 100 occurences of testing so just quite a lot of individual cases

Any chance it could be covered by generative tests?

well a few days ago i was all enthusiastic to use test.check, but sadly this codebase is both clj+cljs and async, and i couldn't see any way of making test.check work with it

Uhh, very carefully?

i'm already using a set of modified deftest and testing macros to give me uniform async tests on both clj and cljs ... and afaics test.check would need a rewrite to work with async, so i gave up on it

what's the actual manifestation of 'unwieldy'?

Isn't this what #C7Q9GSHFV's rcf is for?

@U0509NKGK i find files of >500loc increasingly hard to navigate, extremely hard when &gt;1000loc... on files &lt;500loc i can navigate very quickly by the "visual shape" of the code, but the bigger the file gets the less i seem able to do that... so i prefer files to be <~500loc

dyu mean this hyperfiddle @UK0810AQ2? https://github.com/hyperfiddle/hyperfiddle-2020

This https://github.com/hyperfiddle/rcf

ah, ok - yeah, rcf seems to have the aim of unifying clj + cljs tests ... i don't think that would be any more compatible with test.check though

It also supports async

yep... i have no problem with that though - i have macros which support async tests on clj+cljs, and the tests look and behave almost exactly the same as vanilla clojure.test/deftest tests

I've enjoyed 3 for a few years. Strict API/impl separation in sources and tests with a simple 1:1 mapping. No privacy, keeping the deftests hack-free. I'd go as far as linting that no single ns can exceed ~300LOC - at that point, more often than not things start getting complect-y. (also, code reloading gets faster if you're into reloading one ns at time. Be it with require :reload or tools.namespace)

i find that having a truly reliable lsp go-to-definition is making the line count less of a problem for me. we maintain a 10 year old 150kloc clj[sc] codebase, we've long since left being able to remember where stuff behind, and now lean into knowing how to look for it efficiently

however when doing substantial work on a piece of code, that's where pulling things apart into separate nses tends to happen 😅

Imagine multiple mini windows where the definitions spread out of the form under view like a tree

@U0509NKGK i have a similar size codebase, not quite so old ... and have plenty of opportunities to let sleeping dogs lie 😬 ... but in this case i'm taking one of the foundational libraries and refactoring/rewriting it with the learning of all those years, so everything is up for grabs

@U45T93RA6 what's your favoured technique for referring to impls from APIs ? i've been using simple defs recently, since clj+cljs is more important to me than the nice metadata transparency you get with things like potemkin/import-vars

@U0509NKGK totally agree that ability to navigate across a complete codebase is very important as the codebase gets larger ... i abandoned spacemacs because it's nav was too laggy (doom + CIDER is working well for me now)