The JitPack build for mod compatibility seems to be failing due to the script for getting a newer JDK version not existing anymore:

Running before_install command:
wget https://github.com/sormuras/bach/raw/master/install-jdk.sh;source install-jdk.sh --feature 17
--2023-05-16 16:47:54--  https://github.com/sormuras/bach/raw/master/install-jdk.sh
140.82.113.3
Connecting to github.com (github.com)|140.82.113.3|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2023-05-16 16:47:54 ERROR 404: Not Found.

/script/buildit.sh: line 60: install-jdk.sh: No such file or directory

Additionally, I'm not sure if it is possible to depend on an Architectury mod from a Fabric mod (https://github.com/mschae23/grind-enchantments). If it isn't, it should also be possible for the compatbility to be added from your side by using the ApplyLevelCostEvent.

I'm also not sure if Architectury mods can be used as dependencies (maybe in other Architectury builds?), so I just fixed the JitPack build. It built the loom branch successfully, so it should now work if you put

modImplementation 'com.github.Fourmisain:TaxFreeLevels:loom-SNAPSHOT'

as the dependency.

Well, it tries finding the class file for net.minecraft.world.entity.player.Player, so this doesn't work directly. But Architectury does seem to output different JARs for the different platforms, maybe it's possible to depend on one of those directly?
I guess I can test that GitHub Packages; I don't think Jitpack makes it possible to do that, honestly.

Thank you, that does work now.
However, that branch seems to still be on 1.16.5. I'll try the architectury branch as well, maybe Loom knows how to handle that.

Hold on - so is there any issue when compiling against the loom branch?
Because the only thing that should matter is that you can use the TaxFreeLevels class, which has not changed at all between 1.16 and 1.19 (soon to be 1.20).

(I'm actually still compiling against a 1.16 version of Reroll with no issue as well.)

If it was just something you're wondering - it is possible to depend on the output jars, though you'd need to use them locally with implementation files('path/to/mod.jar') or host them somewhere, which is pretty inconvenient and may not be okay due to licensing.
What I ended up doing a lot to add mod compatibility with Forge mods is recreate the basic class structure of the mod I'm depending on, compile my mod, then rip out the (empty) class files after the fact.

You can see this in the architectury-1.16-compat branch, e.g. the build.gradle adds a finalize task, using a custom DeletingFileVisitor to delete the classes, which are defined here.

That way I can write targeted Mixins for other (Forge) mods without actually having to depend on them in the architectury build.

Hold on - so is there any issue when compiling against the loom branch? Because the only thing that should matter is that you can use the TaxFreeLevels class, which has not changed at all between 1.16 and 1.19 (soon to be 1.20).

I guess this is why I didn't have any problems until I tried updating the dependency... compilation succeeds, but the devenv fails to start because the mod has ~1.16.0 as a dependency. So I probably wouldn't have had a problem in production.

If it was just something you're wondering - it is possible to depend on the output jars, though you'd need to use them locally with implementation files('path/to/mod.jar') or host them somewhere, which is pretty inconvenient and may not be okay due to licensing.

I wanted to test using GitHub Packages (basically a Maven repository) for this, which is a bit inconvenient because it requires authentication for public packages, but I'm already using it anyway.

What I ended up doing a lot to add mod compatibility with Forge mods is recreate the basic class structure of the mod I'm depending on, compile my mod, then rip out the (empty) class files after the fact.

Because class files are only loaded at runtime using their full name? That's actually pretty clever. I'll probably end up using either this, or the loom branch with a dependency override for the devenv.

Ah, the dev env breaks. I actually almost never use it, since I find it inconvenient for my uses (I'm basically always debugging compatibility issues with mods/modpacks, so I instead symlink the output jar to a MultiMC instance).

Hm... I think you can use modCompileOnly instead of modImplementation, so it won't load the mod in the dev env.
You can probably add the Tax Free Levels jar to the dev env manually when you need to.

I was thinking of stripping down the loom branch to it only contains the TaxFreeLevels class and no fabric.mod.json requirements and mixins, that way it'll run with any version and you can test the methods too - though Mixin compatibility still would need to be tested, so maybe I'll just port the latest architectury version to loom 1.19.

Just did a loom port (which weirdly just would not build with Charm support) and updated the loom branch.
You should now be able to use
modImplementation 'com.github.Fourmisain:TaxFreeLevels:loom-SNAPSHOT'
or
modImplementation 'com.github.Fourmisain:TaxFreeLevels:loom-1.18-SNAPSHOT'
(JitPack doesn't seem to want to build the loom branch right now, will try again later)

I also added a loom-nomixins branch that's the stripped down version I talked about, if you just wanna use the TaxFreeLevels class and don't care about mixins.

Alright, I think I am going to go with modCompileOnly, I didn't remember that this doesn't add the mod to the dev env. Thank you for your efforts!