A query string in a plugin's file:// path causes a duplicate load and a duplicate route

[Dogwind221]

Repro

Register a local plugin with a cache-busting query string on the file:// path:

- insert:
    - id: live-workbench
      name: 'file:///F:/.../plugin/dsh-live-workbench/dist/plugin.js?v=2'

Expected

The plugin loads once; ?v=2 is treated as a harmless suffix (or rejected up front).

Actual

The package name fails to resolve correctly. The same plugin ends up loaded twice, and the second registration throws duplicate route for the prefix route it registers — the whole plugin tree fails at boot.

Evidence

I hit this on my web profile (an entry for media-studio broke exactly this way and took a restart cycle to diagnose). Switching to a clean file:// URL with no query string fixed it immediately.

Suggestion

Either:

1. Normalise — strip the query string before resolving the package name, so a cache-busting suffix can't change identity; or
2. Reject loudly — if a file:// path contains ?, stop with an explicit error along the lines of "query strings are not supported in plugin paths; use a clean path".

Right now the failure mode is a duplicate-route stack from somewhere else in the tree, which doesn't point at the real cause. A clear error at parse time would save the restart-and-guess loop.

Environment

• DSH desktop, local plugins mounted with file:// paths in a profile cordis.patch.yml
• Same plugin path with and without ?v= compared side by side

[Dogwind221]

Agreed — I'll drop the "blanket ban" framing. The concrete failure I hit was that a query string in a file:// registration path broke package-name resolution, and the same plugin ended up mounted twice (duplicate prefix route). That's a resolution problem, not an argument that query strings are invalid — Node does treat them as distinct module identities, as you note.

Reframing to what I think is actually actionable:

1. Normalise or explicitly ignore the query string when resolving the package name for a plugin path, so plugin.js?v=2 cannot change identity.
2. If query strings are unsupported for registration, reject them at parse time with a clear error instead of letting the duplicate mount surface as a duplicate-route stack from somewhere else in the tree.
3. If they are supported as distinct identities, a line of documented behaviour would help — e.g. "the query string is part of the module identity; mounting the same path with two different queries yields two instances".

Keeping this separate from the HMR thread as you suggested. For source HMR I now use a clean, stable registration URL plus the hmr entry's base/root, and reload works without touching the patch. Packaged-Desktop results are in #10774.