Start with modrinth.index.json
The modrinth.index.json file is the authoritative pack definition. It identifies the pack format, Minecraft/loader dependencies, files, hashes, download locations, sizes and environment requirements. The importer should read the manifest before scanning the archive for loose JARs or trying to auto-install dependencies.
Create a dedicated instance
A pack can require a different Minecraft version or loader from the instance currently selected in the launcher. Rather than silently changing that unrelated instance, SPUDZWARE should prepare a dedicated modpack instance with the version and loader declared by the pack. The user can then review the plan before the large download starts.
Download and verify declared files
Each declared file should be downloaded from its manifest URL, cached when safe, and verified against the supplied SHA-1 or SHA-512 hash. A failed hash is not “close enough”; the file should be rejected and retried or reported as damaged. The final instance should be promoted from staging only after the required files validate.
Nested Fabric JARs are not top-level duplicates
Fabric mods can contain nested JAR-in-JAR dependencies, and Fabric API itself is composed of many modules such as resource loader, rendering, lifecycle and command APIs. Scanning every embedded fabric.mod.json and treating each discovered ID as a separate top-level mod creates false duplicate errors.
The effective loader model needs to distinguish a file in the instance's mods directory from a dependency embedded inside another approved mod. The same principle applies when a mod bundles helper libraries. Duplicate detection is still useful, but it should target real conflicts such as two different top-level Sodium JARs in the same instance.
If sodium-0.8.7.jar and sodium-0.8.8.jar are both top-level files, the launcher should report that conflict clearly. If a Fabric module appears only as a nested dependency inside another mod, that is not automatically a conflict.
Do not auto-install what the pack already supplies
The importer should check the pack before adding Fabric API, Mod Menu, Sodium, Iris, voice chat dependencies or other helpers. Pack-provided dependencies should win unless something required is genuinely absent. This avoids creating the exact duplicate the resolver later complains about.
Apply overrides safely
Modrinth packs can include overrides/ and client-overrides/. These often carry configuration, resource packs, shader packs or options that make the pack behave as intended. SPUDZWARE should apply them to the staged pack instance, not to every Minecraft instance on the device.
Errors should be human-readable
A normal user should see “2 mods need attention”, the affected mod names and a safe action. The full resolver object, raw JSON and hundreds of duplicate-ID entries belong under technical details or logs. Useful categories include Missing dependency, Incompatible Minecraft version, Loader mismatch, Real duplicate mod and Corrupt download.
Interrupted imports
An interrupted pack import should reuse verified cached files and continue from the last safe stage. It should not leave the destination instance half-promoted. If the final validation fails, the previous instance state should remain intact and the staged data can be repaired or discarded.