fix: use full URL for file:// plugin deduplication

[coleleavitt]

Summary

Fixes a bug in plugin deduplication logic where multiple file:// plugins with the same filename (e.g., index.js) would be incorrectly treated as duplicates and only the last one would load.

Problem

The getPluginName() function extracted only the filename for file:// URLs:

// Before
if (plugin.startsWith("file://")) {
  return path.parse(new URL(plugin).pathname).name  // "index"
}

This caused issues when using multiple plugins with standard entry points:

{
  "plugin": [
    "file:///path/to/plugin-a/dist/index.js",  // -> "index"
    "file:///path/to/plugin-b/dist/index.js",  // -> "index" (duplicate!)
    "file:///path/to/plugin-c/dist/index.js"   // -> "index" (duplicate!)
  ]
}

Result: Only the last plugin loaded because all were seen as duplicates of "index".

Solution

Use the full URL as the identity for file:// plugins:

// After
if (plugin.startsWith("file://")) {
  return plugin  // Full URL
}

This allows:

• ✅ Multiple plugins in the same directory with different filenames
• ✅ Multiple plugins in different directories with the same filename
• ✅ Same file:// URL appearing twice → correctly deduplicated
• ✅ npm packages continue to deduplicate by package name as expected

Testing

Verified with real-world setup using four local file:// plugins, all with index.js or index.mjs entry points:

• custom-toolkit-alpha/dist/index.js
• custom-toolkit-beta/dist/index.js
• custom-toolkit-gamma/dist/index.js
• custom-auth-plugin/index.mjs

Before fix: Only the last plugin loaded.
After fix: All four plugins load correctly.

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

No duplicate PRs found

[coleleavitt]

Fixes #8759

[rekram1-node]

But now someone w/ oh-my-opencode installed that is working in oh-my-opencode repo will have the plugn registered twice right

[coleleavitt]

@rekram1-node Re: your review comment about duplicate registration when working in oh-my-opencode repo:

Good catch. Yes, that's true - if someone has oh-my-opencode configured as a plugin AND is working inside the oh-my-opencode directory (which has its own opencode.json referencing itself), the plugin would load twice.

However, this is actually the existing behavior that my PR preserves. The deduplication happens by checking seen.has(name) - if two different file:// URLs point to the same plugin, they're still different strings and both load.

The alternative would be to resolve to an absolute canonical path and dedupe on that, but that adds complexity and might break legitimate use cases (symlinks, mounted volumes, etc.).

Should I add canonical path resolution, or is the current behavior acceptable?

[coleleavitt]

Updated based on feedback from Discord user @ops:

What Changed

Restored the package.json lookup that was previously removed. This is the correct approach.

Why package.json is Better

1. Cross-platform: Avoids path.sep issues that cause 40+ test failures on Windows
2. Canonical naming: Uses actual package name instead of guessing from paths
3. Fixes duplicate registration: Same plugin loaded from different paths (global + local repo) now dedupes correctly because they share the same package.json name
4. Proper scoped packages: Handles @scope/name correctly

The Windows Problem

@ops pointed out that file:// plugins are completely broken on Windows. The issue:

• filePath.split(path.sep) mixes OS-specific paths (\ on Windows) with URL paths (always /)
• This breaks path parsing and causes widespread test failures

The Solution

Read the canonical name from package.json:

// file:///home/user/.opencode/plugins/oh-my-opencode/dist/index.js
// → reads package.json → "oh-my-opencode"

// file:///home/user/projects/oh-my-opencode/dist/index.js  
// → reads package.json → "oh-my-opencode"

// Both dedupe correctly now!

Fallback to path heuristic when package.json not found.

This addresses both the Windows compatibility issue and the duplicate registration concern raised by @rekram1-node.

[cyberprophet]

FYI — I've opened #15598 with a similar fix but a different approach: instead of using the full URL as identity, it extracts the npm package name from node_modules paths (handling @scoped packages too) while keeping the existing filename fallback for local plugins. CI is passing.

This preserves the original design intent where a local my-plugin.js can override an npm my-plugin@1.0.0 by name, while fixing the index.js collision.

[coleleavitt]

Superseded by #16200 which is rebased on latest dev and uses a cleaner implementation (package.json lookup + realpath fallback).

[coleleavitt]

Closing in favor of #16200