Closed Keyrxng closed 4 days ago
Might need to reopen this pull to exclude the template diff
I pretty much abandoned my approach used in this PR but used the manifest fetching logic in #13.
I realized that it's cleaner to just parse manifests directly from the marketplace than to parse our configs for active
plugins then fetch them via the pluginUrl
because there shouldn't be an unstable or inactive plugin within the -marketplace
repo.
If you look at the worker URL keys in localStorage they look kinda messy. We should update them to all have uniform names if possible.
Also because this proved to be a problem recently that configs contained outdated worker endpoints so fetching the manifest that way failed for more than a few.
@Keyrxng, this task has been idle for a while. Please provide an update.
This PR is included in https://github.com/ubiquity-os/ubiquity-os-plugin-installer/pull/13.
When https://github.com/ubiquity-os/ubiquity-os-plugin-installer/pull/13 is merged we should:
Resolves #4
Why I choose to do it like this:
ubiquityos-config.yml
, that's all the plugins which are active and installable (in theory as quite a few produce errors when fetching their manifest)I could just read the
manifest.json
directly from each repo in-marketplace
instead if that's the 'official' marketplace for installable plugins.You've always been the CSS guy between us @0x4007, I lack the finesse, maybe a task specifically for handling the huge configs and designing config customizations
QA:
If you look at the worker URL keys in
localStorage
they look kinda messy. We should update them to all have uniform names if possible.