Modrinth search: filter by server type so mods and plugins do not mix (#47 pt 1) - #61
Merged
Merged
Conversation
Modrinth search: filter by the server type so mods and plugins do not mix (#47 pt 1) The browse search filtered by a single Modrinth loader (MR_LOADER[type]), so a Paper server missed plugins tagged only spigot/bukkit, and nothing kept the result set to the right kind for the server. - New pure searchLoaders(type) in core/mods.ts: plugin servers get the whole Bukkit family (paper/purpur/folia/spigot/bukkit), modded/proxy stay single, and a HYBRID (mohist/arclight) unions the plugin family with its mod loaders (forge) so both plugins and mods show — the issues explicit hybrid case, which loadersFor() alone does NOT satisfy (mohist is in both families, so it resolves to paper-only there). - searchModrinth now filters by searchLoaders() as an OR facet. Because the loader taxonomies are disjoint (nothing is tagged both `paper` and `fabric`), this is what stops a Fabric server from listing plugins and vice-versa. - Deliberately NOT filtering by project_type: verified against the live Modrinth API that plugins are indexed as project_type "mod", so a project_type:plugin facet would return zero plugins — a regression. The loader facet is the correct separator. - MSMS_SMOKE_MODUPDATE: pure unit for searchLoaders (plugin family, modded single, hybrid unions both, vanilla unfiltered). Part of #47; the detail view + compatibility line follow in a second PR. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> @
This was referenced Jul 24, 2026
CaYatur
added a commit
that referenced
this pull request
Jul 27, 2026
* Modrinth: project detail + per-server compatibility line Part 2 of the richer Modrinth tab. Part 1 (PR #61) filtered browse results by server type; this adds the detail view and, with it, the compatibility verdict. - shared/mods.ts: pure pickCompatibleVersion(versions, {mcVersion, loaders}). Same doctrine as diffUpdates - a version_number is arbitrary text and is never compared as if it sorted. Recency comes from date_published, and a stable release outranks a newer beta/alpha. Also folderForLoaders(), and PLUGIN_LOADERS moved here so the update check and the folder decision cannot drift apart. - core/mods.ts modrinthDetail(): project + versions + members in one call each, versions fetched UNFILTERED so the UI can tell "nothing for your Minecraft version" apart from "nothing for your loader". Compatibility is computed against searchLoaders(type) - the same set browse was filtered by - so a listed result can never claim a compatibility the install then refuses. - installModrinth(): now picks via the same pure function, accepts an optional versionId that is validated against the project's own version list, and takes the target folder from the chosen version's loaders instead of the server type. A hybrid (mohist/arclight) runs Bukkit plugins AND Forge mods, so type alone dropped every plugin into mods/. - ModsView: expandable detail per result - compatibility line, author, downloads, followers, license, categories, description, external links. Late replies are discarded if the card was collapsed meanwhile; switching servers clears results and detail (they carry the old server's loader verdict). - en/tr keys in lockstep (42/42). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Review fixes: stale-detail race and an overclaimed MC compatibility line Two problems found reviewing the branch. 1. toggleDetail ran setDetail/setDetailState inside a setOpenId updater. State updaters must be pure - React double-invokes them in StrictMode - and the projectId it compared could not tell a re-opened card's new request from its own stale one. Replaced with a monotonic request sequence in a ref; close and server-switch both bump it, so any in-flight reply is dropped. 2. pickCompatibleVersion is deliberately lenient about a version that declares no game_versions, but the UI rendered that as a definite 'X supports MC Y'. The line now only names the MC version when the build actually lists it, and falls back to the softer 'latest matching version' wording otherwise. --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #47 (does not close it — the detail view + compatibility line follow in a second PR). First of the UX & access pass's Modrinth work.
Why
The browse search filtered by a single Modrinth loader (
MR_LOADER[type]), so a Paper server missed plugins tagged onlyspigot/bukkit, and nothing kept the result set to the kind of add-on the server can actually run.Changes
searchLoaders(type)incore/mods.ts:paper/purpur/folia/spigot/bukkit);forge), so both plugins and mods show — the issue's explicit hybrid case, whichloadersFor()alone does not satisfy (mohist is in both families, so it resolves to paper-only there).searchModrinthnow filters bysearchLoaders()as an OR facet. Because the loader taxonomies are disjoint (nothing is tagged bothpaperandfabric), this is exactly what stops a Fabric server from listing plugins and vice-versa — item Epic: Stage 15 — Audit trail completion #1 of the issue.project_type: verified against the live Modrinth API that plugins are indexed asproject_type: "mod", so aproject_type:pluginfacet would return zero plugins for every Paper server — a regression. The loader facet is the correct separator (documented in a code comment so it isn't "fixed" later).Verify
typecheck,build— pass.MSMS_SMOKE_MODUPDATEPASS, new unit:searchLoadersgives the plugin family for plugin servers, a single loader for modded/proxy, the union for a hybrid (mohist → paper/spigot/bukkit/forge), and nothing for vanilla.project_typefinding were checked against a liveapi.modrinth.com/v2/searchresponse (the live search itself stays inspection-only).Next (PR2, closes #47)
A detail view on opening a result — description, author, downloads, license, links — and a compatibility line: whether a version exists for this server's MC version + loaders, reusing the update-checker's matching. That part depends on Modrinth version-endpoint shape, hence the split.