install-win: Führe bei NPM Post-Install-Skripte bei Bedarf aus

2 files changed, 14 insertions, 4 deletions

diff --git a/bootstrap-win/neovim.ps1 b/bootstrap-win/neovim.ps1
index a20f291..aa17dcf 100644
--- a/bootstrap-win/neovim.ps1
+++ b/bootstrap-win/neovim.ps1
@@ -118,7 +118,7 @@ function Test-BinaryRuns([string]$Binary, [string[]]$VerifyArgs) {
   }
 }
 
-function Install-NpmPackage([string]$Binary, [string]$Package, [string[]]$VerifyArgs = $null) {
+function Install-NpmPackage([string]$Binary, [string]$Package, [string[]]$VerifyArgs = $null, [switch]$AllowScripts) {
   if (Test-CommandExists $Binary) {
     if ($VerifyArgs -and -not (Test-BinaryRuns $Binary $VerifyArgs)) {
       Write-Warn "'$Binary' ist im PATH, laesst sich aber nicht ausfuehren - vermutlich hat der Post-Install-Download von '$Package' nicht geklappt (Proxy/ignore-scripts pruefen). 'npm uninstall -g $Package' und neu installieren."
@@ -133,8 +133,17 @@ function Install-NpmPackage([string]$Binary, [string]$Package, [string[]]$Verify
     return
   }
 
-  Write-Step "npm install -g $Package"
-  npm install -g $Package | Out-Null
+  # -AllowScripts: fuer Pakete wie tree-sitter-cli, deren Post-Install-Skript
+  # die eigentliche native Binary von GitHub nachlaedt. Die globale
+  # ignore-scripts=true in der npmrc wuerde das verhindern; --no-ignore-scripts
+  # hebt das nur fuer diesen einen Aufruf auf, ohne die npmrc anzufassen.
+  $npmArgs = @("install", "-g", $Package)
+  if ($AllowScripts) {
+    $npmArgs += "--no-ignore-scripts"
+  }
+
+  Write-Step "npm $($npmArgs -join ' ')"
+  npm @npmArgs | Out-Null
 
   if ($LASTEXITCODE -ne 0) {
     Write-Warn "npm install -g $Package fehlgeschlagen."
@@ -182,7 +191,7 @@ function Install-Formatters {
 function Install-Tools {
   Install-WingetPackage -Binary "rg" -Id "BurntSushi.ripgrep.MSVC"
   Install-WingetPackage -Binary "fd" -Id "sharkdp.fd"
-  Install-NpmPackage -Binary "tree-sitter" -Package "tree-sitter-cli" -VerifyArgs @("--version")
+  Install-NpmPackage -Binary "tree-sitter" -Package "tree-sitter-cli" -VerifyArgs @("--version") -AllowScripts
 
   # MSVC (cl.exe) ist bereits vorhanden, kein winget-Paket noetig - Neovim
   # dafuer aber aus einer "Developer PowerShell for VS" starten.
diff --git a/neovim-windows-setup.md b/neovim-windows-setup.md
index 0fbeefe..c2a4df6 100644
--- a/neovim-windows-setup.md
+++ b/neovim-windows-setup.md
@@ -70,6 +70,7 @@ $userPath = [Environment]::GetEnvironmentVariable("PATH", "User")
 ## 4. Bekannte Stolpersteine
 
 - **C-Compiler für `nvim-treesitter` (MSVC)**: `cl.exe` findet `nvim-treesitter` automatisch, aber nur wenn `INCLUDE`/`LIB` gesetzt sind – das passiert ausschließlich in einer "Developer PowerShell for VS" bzw. "x64 Native Tools Command Prompt", nicht in einer normalen PowerShell/Windows Terminal-Sitzung. Ohne das schlägt die Parser-Kompilierung mit einer Meldung wie "cannot find `<header>`.h" fehl, obwohl `cl.exe` selbst gefunden wird. Neovim also immer aus dieser Developer-Shell heraus starten.
+- **clangd bei MSVC-Projekten (z. B. mit `compile_commands.json` aus einem `msbuild`-Rebuild)**: gleicher Grund wie oben. Eine generierte `compile_commands.json` enthält nur die projektspezifischen `/I`-Pfade (vcpkg, NuGet-SDKs), nicht die MSVC-STL-/Windows-SDK-Header – die bezieht `clang-cl` (wie `cl.exe`) über `INCLUDE`/`LIB`. Ohne Developer-Shell meldet clangd `<string>`/`<windows.h>` etc. als nicht gefunden, obwohl die Projekt-Header aufgelöst werden.
 
 ## 5. Verifizieren