Contesto
Analisi del meccanismo di upgrade di nikcli (CLI + installer). Sono emersi diversi bug che impediscono un aggiornamento corretto, in particolare su Windows. Il binario installato restava fermo a v1.244.0 nonostante l'installer dichiarasse il successo.
Bug identificati
Critici
-
Strategia di upgrade sbagliata su Windows (tutti i metodi)
resolveUpgradeStrategy() usava sempre l'installer PowerShell (irm https://nikcli.store/install.ps1 | iex) su win32, ignorando il metodo di installazione reale. Con installazioni via package manager (npm/yarn/pnpm/bun/brew/choco/scoop), lo shim del manager su PATH fa ombra a ~/.nikcli/bin: l'installer standalone 'riesce' ma il comando realmente eseguito dall'utente resta sulla versione vecchia.
-
yarn rilevato ma mai gestito
yarn veniva rilevato come metodo ma mancava il case nello switch: risultava Unknown method: yarn. (Le scelte della CLI non includevano nemmeno yarn.)
-
Nessuna verifica che l'upgrade sia avvenuto davvero
Dopo l'esecuzione del comando di upgrade si stampava 'Upgrade complete' fidandosi solo dell'exit code, senza verificare la versione installata. Un upgrade fallito silenziosamente (es. binario lockato su Windows) appariva come riuscito.
Medi
-
Scoop: metodo fantasma
scoop non è pubblicato nel bucket Main di ScoopInstaller (404): errore poco chiaro.
-
Chocolatey: Accept JSON rifiutato
L'API OData di Chocolatey rifiuta Accept: application/json (HTTP 400) e serve Atom/XML; il codice parsava data.d.results[0] che non esisteva. Inoltre era hardcoded il messaggio 'not running from an elevated command shell' per ogni errore.
-
Homebrew: formula core assente
formulae.brew.sh/api/formula/nikcli.json restituisce 404 (la formula nikcli è nel tap, non nel core): il fetch falliva senza fallback.
Basso
- Toast 'Update Failed' vuoto nel TUI
UpgradeFailedError porta la causa reale in stderr, non in message; il toast mostrava quindi un messaggio vuoto.
Comportamento osservato (riproduzione)
Su Windows, dopo nikcli upgrade, l'installer scaricava la nuova versione ma il binario nikcli.exe era lockato da processi attivi: il deferred swap rinunciava silenziosamente e nikcli --version restava alla vecchia versione. La verifica mancante rendeva il problema invisibile.
Correzioni proposte
Vedi PR collegata: strategia corretta per package manager, case yarn e fallback unknown, verifica post-upgrade su non-Windows (nikcli --version vs target), parse Atom/XML per choco, errore chiaro per scoop, guardia per brew, toast con stderr.
Extra scoperti lungo il percorso (pre-esistenti, non correlati)
packages/app/src/custom-elements.d.ts e packages/enterprise/src/custom-elements.d.ts contenevano il path nudo invece del triple-slash reference (rompe tsc -b con TS1128 in @nikcli-ai/desktop ed enterprise).
Contesto
Analisi del meccanismo di upgrade di nikcli (CLI + installer). Sono emersi diversi bug che impediscono un aggiornamento corretto, in particolare su Windows. Il binario installato restava fermo a v1.244.0 nonostante l'installer dichiarasse il successo.
Bug identificati
Critici
Strategia di upgrade sbagliata su Windows (tutti i metodi)
resolveUpgradeStrategy()usava sempre l'installer PowerShell (irm https://nikcli.store/install.ps1 | iex) su win32, ignorando il metodo di installazione reale. Con installazioni via package manager (npm/yarn/pnpm/bun/brew/choco/scoop), lo shim del manager su PATH fa ombra a~/.nikcli/bin: l'installer standalone 'riesce' ma il comando realmente eseguito dall'utente resta sulla versione vecchia.yarnrilevato ma mai gestitoyarnveniva rilevato come metodo ma mancava il case nello switch: risultavaUnknown method: yarn. (Le scelte della CLI non includevano nemmenoyarn.)Nessuna verifica che l'upgrade sia avvenuto davvero
Dopo l'esecuzione del comando di upgrade si stampava 'Upgrade complete' fidandosi solo dell'exit code, senza verificare la versione installata. Un upgrade fallito silenziosamente (es. binario lockato su Windows) appariva come riuscito.
Medi
Scoop: metodo fantasma
scoopnon è pubblicato nel bucket Main di ScoopInstaller (404): errore poco chiaro.Chocolatey: Accept JSON rifiutato
L'API OData di Chocolatey rifiuta
Accept: application/json(HTTP 400) e serve Atom/XML; il codice parsavadata.d.results[0]che non esisteva. Inoltre era hardcoded il messaggio 'not running from an elevated command shell' per ogni errore.Homebrew: formula core assente
formulae.brew.sh/api/formula/nikcli.jsonrestituisce 404 (la formula nikcli è nel tap, non nel core): il fetch falliva senza fallback.Basso
UpgradeFailedErrorporta la causa reale instderr, non inmessage; il toast mostrava quindi un messaggio vuoto.Comportamento osservato (riproduzione)
Su Windows, dopo
nikcli upgrade, l'installer scaricava la nuova versione ma il binarionikcli.exeera lockato da processi attivi: il deferred swap rinunciava silenziosamente enikcli --versionrestava alla vecchia versione. La verifica mancante rendeva il problema invisibile.Correzioni proposte
Vedi PR collegata: strategia corretta per package manager, case
yarne fallbackunknown, verifica post-upgrade su non-Windows (nikcli --versionvs target), parse Atom/XML per choco, errore chiaro per scoop, guardia per brew, toast constderr.Extra scoperti lungo il percorso (pre-esistenti, non correlati)
packages/app/src/custom-elements.d.tsepackages/enterprise/src/custom-elements.d.tscontenevano il path nudo invece del triple-slash reference (rompetsc -bcon TS1128 in @nikcli-ai/desktop ed enterprise).