[Feature] Add plugin dependencies (prerequisite for third-party localization)

[WkdXeqtr]

Before Requesting

• I found no existing issue matching my feature request
• This request is related to Millennium, and not a request for a specific theme/addon

Describe the feature you'd like!

You said a plugin localization system could work but would need proper planning, so here it is. The short version: I want third parties to be able to ship translations for plugins they don't own, and for that a plugin needs to be able to depend on another and load after it. So dependencies come first, localization builds on top. This is the dependency design - I want your take before I write any code, and it would land in both Millennium and the PluginTemplate.

Add an optional dependencies to plugin.json - a list of internal plugin names (the same name the loader already uses), with an optional semver range since CMP_VERSION already exists:

"dependencies": ["steam-some-plugin", "another-plugin@>=1.2.0"]

On install. No auto-installing anything - same stance you took on the sidebar PR. If a plugin has missing dependencies, the installer shows a dialog listing them and lets the user install anyway or cancel. The plugin is expected to degrade gracefully if a dependency is absent.

Resolution. Check what's actually on disk, so a dependency someone installed manually counts. Three states: missing, present but disabled, present and enabled. Each dependency name is resolved to its page via the same plugin API the installer uses, shown as a link; if the lookup fails, show the raw id.

Load order. Backends already all start before any frontend, but the order among them is arbitrary, so I'd topologically sort the spawn order (cycle detection falls back to current order with a warning). Frontends have no ordering at all today since the shims are appended as async module scripts, so I'd sort them in dependency order and make injection ordered. Plus a Millennium.whenPluginReady(name) as a safety net.

openQuickAccess({ plugin }) fits here as a compatibility affordance: a plugin can deep-link into a dependency's settings panel, including from the dependency dialog.

How localization uses this (for context): a plugin ships a locales/ folder with english.json as the source of truth, plus a small helper in the SDK (same pattern as the core locale manager). A translation plugin then depends on the target and contributes its strings to a shared registry in core - it has to be in core because plugins run in isolated worlds and can't patch each other directly. The target's lookup merges its own strings with any contributed overrides. No target installed means the translation plugin is a no-op. I'm not trying to extract strings from old plugins; a plugin is localizable once it adopts the system.

A few open questions:

• Dependencies referencing internal name with optional name@range - good, or bare names only for v1?
• Warn-and-allow vs hard block on missing deps. I lean warn.
• The ordered frontend loading touches the loader and shim injection - want me to take a pass at it, or own that part yourself like you did with quick access?

Anything else?

References for context:

• Millennium.openQuickAccess({ plugin }) from the quick access work in next.
• Version comparison already wired through the CMP_VERSION IPC in the plugin loader.
• The core locale manager (src/typescript/frontend/utils/localization-manager.ts) as the pattern for the per-plugin helper.

[WkdXeqtr]

This would also cover #102 (themes depending on plugins). The dependencies field and load ordering are generic, so a theme's skin.json could declare a plugin dependency the same way - same no-silent-install rule: the user gets a prompt with a link, and the plugin loads before the theme.

[shdwmtr]

I don't fully understand what this accomplishes though, why can't plugins just ship their own locales? If two plugins want to share the same locales, they can setup some sort of transport layer between them. I don't see why Millennium has to be the mediator.

[WkdXeqtr]

Sure, a plugin shipping its own locales needs no mediator, just a small SDK helper. The point is third-party translations. An author only ships the languages they speak, English and maybe one more, so most plugins are never gonna get localized well, or at all. Today the only way for someone else to translate a plugin they don't own is to fork it, or PR the author and hope for a re-release. What I want: anyone can publish a translation for any plugin, and the target author does nothing - no integration code, no PRs, no re-release.

A per-plugin transport layer can't deliver that:

a) Plugins run in isolated worlds, so any channel between them already has to go through a shared layer (MILLENNIUM_API / backend). That's Millennium mediating regardless.

b) Load order isn't handled at all right now, so every plugin would have to solve ordering itself just to apply locales in time.

c) It only works if both sides opt in, and the whole point is that the target implements nothing.

So the mediation is tiny: a translator contributes overrides, the target's lookup merges them, and the dependency just says "load me after plugin X." None of it asks anything of X's author.

Same shape as #102: the alternative is every author hand-rolling glue for each integration - bundling, ordering, coordinating - instead of declaring a dependency once and letting Millennium handle it. Localization is just the case where the target author has to do nothing at all.

[WkdXeqtr]

So, what do you think of the plan overall? I'd like to settle the dependency piece now rather than have to reopen it later, and I'm happy to take a first pass at the implementation myself.

If you'd rather leave dependencies for now, we could ship just the plugin-side localization first. The downside is authors would then have to migrate a second time once dependencies land, since the override mechanism sits on top of them. And authors aren't going to wire up dependencies themselves just to let other people translate their plugins, so it pretty much has to be built into the platform for it to ever happen.

[shdwmtr]

Drafting a PoC PR would be the easiest way I could review your FR. I can't guarantee anything will be accepted though.

[WkdXeqtr]

Got a rough version working locally - the load ordering and the install-time warning. I'll clean it up over the weekend and put up a draft PR.