Describe the bug
Currently, the project relies on mod JARs in the "modsWithCompat" folder of the repository in order to compile.

Declaring dependencies on locally available JARs in a project is a very bad idea, as they're less convenient to update, unnecessarily increase the size of the Git repository, and - most importantly - introduce another potential attack vector for malware that injects itself into JAR files, such as Fractureiser.

It's good practice, and much safer, to declare dependencies using Maven repositories, that are then dynamically downloaded as-needed from official sources.

Instead of declaring a flatDir { } repository, you would add something like Cursemaven and/or Modrinth Maven to the repositories { } block, then declare a dependency on each mod as described in their documentation. (Better yet, you could use the mod's own Maven repository, if they have one.)

To Reproduce
Steps to reproduce the behavior:

1. Build the project.
2. It declares dependencies on mods in the modsWithCompat folder.

Expected behavior
The Gradle build script should declare dependencies on Maven artifacts.

Desktop (please complete the following information):

• OS: N/A
• Minecraft Version: N/A
• Version: >=1.2.5 (322b526)

Additional context
Also, if a given dependency isn't always required to run the mod (such as every mod that loads code conditionally), you can declare a dependency on it using modCompileOnly instead of modImplementation, which may make the mod compile more quickly (IIRC).

Screenshots
N/A

I'm glad you're open to fixing this!

In terms of version IDs, Modrinth Maven allows you to use the version numbers specified by the mods uploaded to it, which are generally more readable / logical than a random string of numbers.

Of the mods in modsWithCompat, only Flan and Inventorio aren't on Modrinth - the former is missing its 1.19.2 version, while the latter isn't present at all.

For modCompileOnly - note that it doesn't include the mod it's declaring a dependency on in the development environment (runClient / runServer); for that, you would want modImplementation. Also note that I'm not great with Gradle dependencies and their formatting, so I may be wrong about it :P

Thanks for tour input. I've already done this in the 1.20 branch, but I'll be sure to change other branches in development now too as soon as I get back to working on them.
I started using the modsWithCompat thing because it seemed easier to handle the version ID there, but when I come to think of it now you're probably right that downloading files is slower and more complicated (as well as potentially more dangerous).
Also I use mods own mavens when I can. Rhe mods in modsWithCompat are those I couldn't find/figure out a maven to.
Also I think I tried once "modCompileOnly", but if I recall correctly, it didn't work properly. I will give it another shot though, and see if it works this time.
Thanks again. I will close the issue whenever I update the 1.19 branch, which probably is the only branch other than 1.20 I will keep updated for now

I honestly don't think I'll bother with versions below 1.20 from now on (maybe on some occasion, but 1.19 seems to work reliably enough for most people anyway). Thank you anyway for explaining the different "dependency" or "inclusion" gradle methods (at least so I actually understand them better). I've started using modCompileOnly in the 1.20 branch, and it seems to be working well, especially since I can still test without some mods being up to date, or having some issues with my dev environment. Thanks!