The PowerShell completion instruction used bash-style environment
variable syntax (`COMPLETE=powershell prek`), which fails in PowerShell
with `CommandNotFoundException`.
## Changes
- Updated `docs/installation.md` to use PowerShell-native syntax for
setting environment variables
**Before:**
```powershell
Add-Content -Path $PROFILE -Value '(COMPLETE=powershell prek) | Out-String | Invoke-Expression'
```
**After:**
```powershell
Add-Content -Path $PROFILE -Value '$env:COMPLETE = "powershell"; prek | Out-String | Invoke-Expression; Remove-Item Env:\COMPLETE'
```
The fix sets `$env:COMPLETE` using PowerShell syntax, invokes `prek` to
generate the completion script, and cleans up the temporary environment
variable.
<!-- START COPILOT ORIGINAL PROMPT -->
<details>
<summary>Original prompt</summary>
>
> ----
>
> *This section details on the original issue you should resolve*
>
> <issue_title>Powershell completion script results in
CommandNotFoundException</issue_title>
> <issue_description>### Summary
>
> Following the instructions for enabling Powershell shell completions,
I ran `Add-Content -Path $PROFILE -Value '(COMPLETE=powershell prek) |
Out-String | Invoke-Expression'`. This did what I expected it to: it
added a line to my $PROFILE, `(COMPLETE=powershell prek) | Out-String |
Invoke-Expression`.
>
> However, also as expected, that line results in this error when the
profile loads (and, indeed, if one types that string at the prompt:
> ```
> COMPLETE=powershell : The term 'COMPLETE=powershell' is not recognized
as the name of a cmdlet, function, script file, or operable
> program. Check the spelling of the name, or if a path was included,
verify that the path is correct and try again.
> At
C:\Users\Patrick\OneDrive\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1:357
char:2
> + (COMPLETE=powershell prek) | Out-String | Invoke-Expression
> + ~~~~~~~~~~~~~~~~~~~
> + CategoryInfo : ObjectNotFound: (COMPLETE=powershell:String) [],
CommandNotFoundException
> + FullyQualifiedErrorId : CommandNotFoundException
> ```
>
> If the problem isn't apparent, perhaps someone can tell me what it's
designed to do so I can help? As a user of both Powershell & unix
shells, I wasn't able to figure out what the command is that we want
Powershell to run after glancing at some of the other completion
scripts.
>
> ### Platform
>
> Windows 10 x86_64
>
> ### Version
>
> prek 0.3.1 (bc142a25f 2026-01-31)
>
> ### .pre-commit-config.yaml
>
> not relevant
>
> ### Log file
>
> 2026-02-05T03:33:51.720707Z DEBUG prek: 0.3.1 (bc142a25f 2026-01-31)
> 2026-02-05T03:33:51.720806Z DEBUG Args: ["c:\\users\\username
\\.local\\bin\\prek.exe"]
> 2026-02-05T03:33:51.803464Z TRACE get_root: close time.busy=82.6ms
time.idle=5.10µs</issue_description>
>
> <agent_instructions>Fix the powershell completion instruction in
installation.md: the style of running command with specified env var
`COMPLETE=powershell prek` is bash-style, it does not work in
powershell. Use something like `$env:COMPLETE = "powershell"; prek |
Out-String | Invoke-Expression; Remove-Item Env:\COMPLETE`
> </agent_instructions>
>
> ## Comments on the Issue (you are @copilot in this section)
>
> <comments>
> <comment_new><author>@j178</author><body>
> Thanks for the report! That instruction isn’t correct. Could you try
adding this to your $PROFILE?
>
> ```pwsh
> $env:COMPLETE = "powershell"
> prek | Out-String | Invoke-Expression
> Remove-Item Env:COMPLETE'
> ```</body></comment_new>
> </comments>
>
</details>
<!-- START COPILOT CODING AGENT SUFFIX -->
- Fixesj178/prek#1566
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: j178 <10510431+j178@users.noreply.github.com>
- Remove `todo.md` as remaining items have been addressed or documented
elsewhere.
- Move note to `diff.md` that `pre-commit hazmat` subcommand (v4.5.0) is
not implemented.
* feat(swift): add Swift language support
Implement Swift language support for prek:
- Query swift executable and parse version from `swift --version`
- Handle both macOS (Apple Swift) and Linux version formats
- Normalize versions without patch component (e.g., "6.1" -> "6.1.0")
- Handle pre-release versions (e.g., "6.2-dev")
- Build Package.swift repos with `swift build -c release`
- Use `swift build --show-bin-path` to resolve target-specific bin directory
- Add built binaries to PATH when running hooks
- Health check verifies swift executable still exists
Include unit tests for version parsing covering:
- macOS format with swift-driver prefix
- Linux format
- Multiline output handling
- Versions without patch component
- Development/nightly versions
- Invalid input handling
* test(swift): add Swift language tests
* docs(swift): mark Swift as supported in language documentation
* ci: stabilize swift toolchain setup across platforms
- pin Swift version in env to keep CI deterministic\n- use SwiftyLab/setup-swift on Windows where swift-actions fails\n- install Swift on macOS and reset TOOLCHAINS back to Xcode\n- force CC/CXX/SDKROOT from Xcode so Ruby native gems compile\n\nThis keeps Swift hooks available while restoring Xcode's clang/SDK,\nwhich avoids msgpack native extension failures on macOS.
* feat(bun): add Bun language support
* test(bun): add integration tests for Bun language support
Add three integration tests covering the key functionality:
- basic_bun: simple hook execution using bun -e
- additional_dependencies: verify deps installed via bunx cowsay
- language_version: test version specification with language_version: "1"
The additional_dependencies test runs twice to verify health_check and
cache reuse works correctly.
* docs: add Bun to supported languages documentation
- Add Bun to toolchain list in README features section
- Add Bun to managed toolchain downloads list in languages.md
- Add full Bun language section with version format documentation
* ci: add Bun setup to test jobs
* feat(bun): use GITHUB_TOKEN to avoid API rate limits
When listing Bun versions from GitHub releases, use the GITHUB_TOKEN
environment variable if available to authenticate requests. This
increases the rate limit from 60 to 5,000 requests/hour.
GITHUB_TOKEN is automatically set in GitHub Actions workflows.
* fix(bun): use consistent bin_dir path on all platforms
Bun installs global packages to $BUN_INSTALL/bin/ on all platforms,
so bin_dir should always return prefix/bin. The Windows special case
was incorrectly copied from Node (which uses npm's different install
structure).
* Add toolchain download test
* Add tests
---------
Co-authored-by: Jo <10510431+j178@users.noreply.github.com>
* chore: slight formatting adjustments
* feat: use zensical
* chore: add uv to mise.toml
* docs: update snippets and snippet markers for includes
* chore: add prek to mise.toml; run prek
* fix: use snippet for changelog instead of symlink
Seems Zensical doesn't like symlinks, a snippet gets the same result
* chore: remove commented-out code
* chore: remove commented-out code; run prek
Jo
Copilot
Shaan Majid
wangxiaolei
Les Freire
Aleksey
jmm
Kevin Gimbel
Matthias Schoettle
Na'aman Hirschfeld
dependabot[bot]
Branch Vincent