Windows: store command collides with Microsoft Store CLI

[OliStarCooke]

Summary

On Windows, the store command name collides with the Microsoft Store CLI shim in WindowsApps, which means a normal store ... invocation can resolve to the wrong executable even after installing this project with go install.

Reproduction

1. Install store on Windows with:

   go install github.com/cushycush/store/v2/cmd/store@latest

2. Make sure C:\Users\\<user>\\go\\bin is on PATH.
3. Run:

   where.exe store
   Get-Command store | Format-List Name,CommandType,Source,Definition

Actual Behavior

On my machine, command resolution prefers the Microsoft Store shim first:

C:\Users\oc004990\AppData\Local\Microsoft\WindowsApps\store.exe
C:\Users\oc004990\go\bin\store.exe

And PowerShell resolves store to:

Name        : store.exe
CommandType : Application
Source      : C:\Users\oc004990\AppData\Local\Microsoft\WindowsApps\store.exe
Definition  : C:\Users\oc004990\AppData\Local\Microsoft\WindowsApps\store.exe

So store apply, store doctor, etc. can invoke the wrong program unless the user calls the Go-installed executable explicitly or adds a PowerShell wrapper/alias.

Expected Behavior

Windows users should have some official guidance or handling for this collision, for example:

• a note in the main README / installation docs
• a Windows-specific troubleshooting entry
• or another mitigation if you prefer a different approach

I hit this while documenting usage in my dotfiles repo and had to add a warning plus a PowerShell wrapper workaround.

[OliStarCooke]

TBH not too sure what can be done for this. It's more of a heads up kind of thing.

My workaround was to add this to my powershell $PROFILE :

function store
{
  & "$HOME\go\bin\store.exe" @args 
}

[cushycush]

Thanks for the bug report. I'll triage and look into how to resolve this.

[cushycush]

@OliStarCooke opened #63 with a fix in two layers: a README install section that documents the collision and the PowerShell $PROFILE wrapper, plus a one-time stderr hint that fires when the binary detects it's being shadowed (so anyone who runs ~\go\bin\store.exe directly gets pointed at the wrapper right when they're confused).

The parser is unit-tested but I don't have a Windows machine to confirm the actual where.exe plumbing fires correctly. If you have a minute, would you mind pulling the branch, building it with go build ./cmd/store, running it from a fresh PowerShell, and confirming you see the hint once and then nothing on subsequent runs? The marker lives at %AppData%\store\windows-shim-hint-shown if you want to delete it and re-test.

git fetch origin fix/windows-store-collision-issue-60
git checkout fix/windows-store-collision-issue-60
go build ./cmd/store
.\store.exe doctor

No rush, and thanks for the original report.

[OliStarCooke]

I'll try and make time for this tomorrow :) Thanks for the quick updates BTW!!!