Skip to content

[fix] Correct dirPlugins() default paths to match specification.md - #94

Merged
kmturley merged 1 commit into
mainfrom
fix/plugins-directory-path
Jul 30, 2026
Merged

[fix] Correct dirPlugins() default paths to match specification.md#94
kmturley merged 1 commit into
mainfrom
fix/plugins-directory-path

Conversation

@kmturley

Copy link
Copy Markdown
Member

Summary

  • dirPlugins() returned bare relative paths that didn't match the spec's directory table (flagged in an internal spec-compliance audit):
    • Linux: spec says $HOME/usr/local/lib — code returned relative usr/local/lib with no $HOME and no leading slash, resolving against process.cwd() instead of a stable location.
    • Windows: spec says C:\Program Files (x86)\Common Files — code returned relative Program Files\Common Files, missing the drive letter and (x86).
    • Mac was already correct.
  • Linux now joins onto os.homedir(), which also keeps the default writable without elevation — consistent with the unprivileged archive-install path added in ManagerLocal.install() for issue Archive plugin installs unnecessarily require administrator elevation #83.
  • Windows now prefers the %ProgramFiles(x86)% env var (matching the existing %APPDATA% pattern already used in dirApp()), falling back to the spec's literal path.
  • Updated tests/helpers/file.test.ts, which had been asserting the old, buggy values — this is why the bug went unnoticed.

Note: this changes the default pluginsDir for existing installs on Linux/Windows. Anyone relying on the old (broken) default location will need to move their files or reconfigure pluginsDir.

Test plan

  • npm run check passes locally (format, lint, build, tests — 191/191, macOS)
  • CI covers all three platforms (ubuntu-latest, macos-latest, windows-latest) — watching for green across all three since this specifically touches the Windows/Linux code paths

🤖 Generated with Claude Code

dirPlugins() returned bare relative paths that didn't match the spec's
directory table:
- Linux: spec says $HOME/usr/local/lib, code returned relative
  "usr/local/lib" with no $HOME and no leading slash - resolves against
  process.cwd() instead of a stable location.
- Windows: spec says C:\Program Files (x86)\Common Files, code returned
  relative "Program Files\Common Files" - missing the drive letter and
  "(x86)".

Mac was already correct. Linux now joins onto os.homedir() (also
keeping the default writable without elevation, consistent with the
unprivileged archive-install path in ManagerLocal.install()). Windows
now prefers the %ProgramFiles(x86)% env var (matching the existing
pattern in dirApp() for %APPDATA%) with the spec's literal path as a
fallback. Updated the test that had been asserting the old, buggy
values.

Note: this changes the default pluginsDir for existing installs on
Linux/Windows - anyone relying on the old default location will need
to move their files or reconfigure pluginsDir.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@kmturley
kmturley merged commit 9799f60 into main Jul 30, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant