CommandSyntaxException on startup with custom book item

[TheRealWormbo]

Mod loader

Fabric

Minecraft version

1.21.1

Patchouli version

1.21-87, 1.21-88

Modloader version

Loader 0.16.10, API 0.115.1+1.21.1

Modpack info

Botania 1.21.1 dev environment

The latest.log file

https://gist.github.com/TheRealWormbo/06ab3dd93c6e6cd70712bcf780685bac

Issue description

There appears to be a mod load ordering issue on Fabric when using book definitions that do not generate their own item. (This issue has not yet popped up on NeoForge for me.)

Botania's lexicon book is defined as follows:

{
  "name": "item.botania.lexicon",
  "landing_text": "botania.landing",
  "version": "${build_number}",
  "book_texture": "patchouli:textures/gui/book_green.png",
  "model": "botania:lexicon",
  "open_sound": "botania:lexicon_open",
  "flip_sound": "botania:lexicon_page",
  "creative_tab": "botania",
  "dont_generate_book": true,
  "custom_book_item": "botania:lexicon",
  "advancements_tab": "botania:main/root",
  "use_resource_pack": true,
  "i18n": true,
  "text_overflow_mode": "truncate",
  "macros": {
    "$(item)": "$(1)",
    "$(thing)": "$(4)"
  }
}

(That build number is filled in by a build script, so it's always a number at runtime.)

Relatively early during startup, Patchouli logs an exception in the render thread:

[23:46:10] [Render thread/ERROR] (patchouli) Failed to load book botania:lexicon defined by mod botania, skipping
 java.lang.RuntimeException: com.mojang.brigadier.exceptions.CommandSyntaxException: Unknown item 'botania:lexicon' at position 0: <--[HERE]
	at knot/vazkii.patchouli.common.util.ItemStackUtil.deserializeStack(ItemStackUtil.java:50) ~[Patchouli-1.21-87-FABRIC.jar:?]
	at knot/vazkii.patchouli.common.book.Book.<init>(Book.java:162) ~[Patchouli-1.21-87-FABRIC.jar:?]
	at knot/vazkii.patchouli.common.book.BookRegistry.loadBook(BookRegistry.java:90) ~[Patchouli-1.21-87-FABRIC.jar:?]
	at knot/vazkii.patchouli.common.book.BookRegistry.lambda$init$3(BookRegistry.java:75) ~[Patchouli-1.21-87-FABRIC.jar:?]
	at java.base/java.util.HashMap.forEach(HashMap.java:1429) ~[?:?]
	at knot/vazkii.patchouli.common.book.BookRegistry.init(BookRegistry.java:70) ~[Patchouli-1.21-87-FABRIC.jar:?]
	at knot/vazkii.patchouli.fabric.common.FabricModInitializer.onInitialize(FabricModInitializer.java:42) ~[Patchouli-1.21-87-FABRIC.jar:?]
	at net.fabricmc.loader.impl.FabricLoaderImpl.invokeEntrypoints(FabricLoaderImpl.java:399) [fabric-loader-0.16.10.jar:?]
	at net.fabricmc.loader.impl.game.minecraft.Hooks.startClient(Hooks.java:52) [fabric-loader-0.16.10.jar:?]
	at knot/net.minecraft.client.Minecraft.<init>(Minecraft.java:447) [minecraft-merged-14fb05758b-1.21.1-loom.mappings.1_21_1.layered+hash.730628366-v2.jar:?]
	at knot/net.minecraft.client.main.Main.main(Main.java:211) [minecraft-merged-14fb05758b-1.21.1-loom.mappings.1_21_1.layered+hash.730628366-v2.jar:?]
	at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:480) [fabric-loader-0.16.10.jar:?]
	at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74) [fabric-loader-0.16.10.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23) [fabric-loader-0.16.10.jar:?]
	at net.fabricmc.devlaunchinjector.Main.main(Main.java:86) [dev-launch-injector-0.2.1+build.8.jar:?]
Caused by: com.mojang.brigadier.exceptions.CommandSyntaxException: Unknown item 'botania:lexicon' at position 0: <--[HERE]

My suspicion is that Patchouli might attempt to load Botania's lexicon before it has access to the actual item definition.

Steps to reproduce

1. Check out and build Botania's 1.21-porting branch
2. Run the Fabric:runClient goal to start the Fabric client version.
3. Hope that your load order works to provoke the bug.

Other information

As far as I can tell, the constructor of vazkii.patchouli.common.book.Book attempts to parse the string supplied as custom_book_item if the dont_generate_book flag is set. Back in 1.20.1 that worked fine because it merely had to produce a resource location, a stack count, and an NBT compound tag, and it parsed that manually.
However, in 1.21.1 the same code relies on net.minecraft.commands.arguments.item.ItemParser, which requires registry access and produces an actual item reference and deserializes actual data components. That is only possible if the mod defining the item has been loaded and has registered its items.

I notice that the parsed data is passed into a lazily-evaluated, memoized supplier. Maybe that's also where the parsing should happen, now that it requires registry access.