Load the plugin store list from store/stores.json - #195
Open
FlazeIGuess wants to merge 3 commits into
Open
Conversation
The plugin store list lives in plugins/ui/src/SettingsPage/PluginStoreTab/index.tsx today, so adding a store needs a code change plus a client release, and removing one never reaches users who already have it persisted. store/stores.json is the list instead. Seeded with the 22 stores currently hardcoded and 7 tombstones recovered from the git history of index.tsx, three of which are hard 404s that have been showing up as error cards for months. store/validate.sh checks schema, unknown keys, url and repo consistency, duplicates and that every active store.json actually resolves with a non empty plugins array. Needs only jq and curl, runs in about 9 seconds.
Flake Review Results for #195Available systems: aarch64-darwin, aarch64-linux, armv6l-linux, armv7l-linux, i686-linux, powerpc64le-linux, riscv64-linux, x86_64-darwin, x86_64-freebsd, x86_64-linux 🔄 Modified (2)
Generated by flake-review |
FlazeIGuess
force-pushed
the
store/registry-json
branch
from
September 4, 2026 15:05
d29ea7f to
3cd17cf
Compare
…ng it Replaces the 22 addToStores calls with a fetch of store/stores.json from raw githubusercontent, pinned to master so a merged store reaches clients without a release. The old storeUrls key mixed defaults and user additions in one list, so removing a default brought it back on the next start and removing one from the code never reached anyone who already had it. Split into three: userStoreUrls for what the user added, hiddenStoreUrls for defaults they dismissed, and the fetched list, which is persisted and doubles as the offline cache. Tombstoned entries drop dead stores from clients that already carry them. The decision logic lives in registry.logic.ts, separate from the reactive state and the fetching in registry.ts. Three things found on the way are fixed here because the wiring touched them: - the deeplink handler lowercased the whole url and pushed it without stripping /store.json, persisting a url that always 404s - Storage.tsx had a second addToStores writing to a different idb store, so adding a store from the themes tab silently went nowhere - LunaStore mapped only the first space in a plugin name and called .filter on unvalidated third party json, which takes down the whole settings page
The [master] Release workflow only runs on pushes to master that touch package.json, so without this the merge would not produce a release build.
FlazeIGuess
force-pushed
the
store/registry-json
branch
from
September 7, 2026 10:59
3cd17cf to
65e478f
Compare
FlazeIGuess
added a commit
to FlazeIGuess/TidaLuna
that referenced
this pull request
Sep 7, 2026
This stacks on Inrixia#195, which bumps to 1.17.0-beta. Each merge to master needs its own package.json touch to trigger the [master] Release build, so this PR carries the next patch.
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
1 participant
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.
Moves the default store list out of
PluginStoreTab/index.tsxand intostore/stores.json, which the client fetches at runtime.Problem
The defaults are 22 hardcoded
addToStores(...)calls inplugins/ui/src/SettingsPage/PluginStoreTab/index.tsx, under a comment that already says what should happen:Because the list lives in client source, adding a store needs a release before anyone sees it. That is what #179, #190 and #194 all are. Removing one has the same problem in reverse: #184 took a dead repo out of the list, but every client built before that merge still tries to fetch it and still shows a red error card. And there is no way to pull a store that turns hostile without shipping a new build.
Change
store/stores.jsonis the list. The client reads it fromraw.githubusercontent.com/Inrixia/TidaLuna/master/store, pinned tomasterdeliberately, so a merged store reaches users in minutes instead of at the next release.store/stores.schema.jsonandstore/validate.shcheck every entry in CI on any PR touchingstore/: url shape, no duplicates, and that eachstore.jsonactually resolves and parses."status": "removed"with a reason rather than deleting the line. Deleting it only stops new clients picking it up; the tombstone is what removes it from clients that already have it.store/blocklist.jsonis a kill switch. Glob patterns, matching stores disappear everywhere on the next fetch.storeUrlskey is migrated once and then deleted. Note thatSettingsPage/Storage.tsxheld a secondstoreUrlson a different idb store, so anything added from the Themes tab was never shown in the store tab. That key is removed rather than migrated.Three fixes ride along because the wiring touched them: the
tidaluna://settings/storedeeplink lowercased the whole url including the store link in its query, plugin names usedreplacewhere they neededreplaceAll, andLunaStorecalled.filteron an unvalidated third partypluginsarray.The store tab looks exactly as it does today. Only the source of the list moves.
Also bumps the version to 1.17.0-beta, since the
[master] Releaseworkflow only runs on pushes tomasterthat touchpackage.json.Validation
All 22 active stores return HTTP 200 with a parseable
store.json, andstore/validate.shpasses on all 29 entries.Tested in the client rather than only built. Because
stores.jsondoes not exist onmasteryet, a plain run only exercises the offline fallback to the oldstoreUrlskey, so I servedstores.jsonlocally, pointed a test build at it and cleared every key the client could fall back on. From that empty state the tab populated all stores with no error rows, and adding a glob to the servedblocklist.jsonmade the matching store disappear on the next fetch.