@Cerlancisme. tapez les commandes suivantes dans PowerShell

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

ou

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

après avoir exécuté votre script PowerShell .ps1

@Clancisme
Dans https://github.com/npm/read-cmd-shim/pull/6 , j'ajoute uniquement le chemin d'extrait du support PowerShell.
Cette fonction est pour https://github.com/npm/cli/pull/281

Si vous voulez savoir pourquoi * .ps est ajouté lors de l'installation du package, veuillez consulter ceci: https://github.com/npm/cmd-shim/pull/34

Les scripts Node.js ( https://github.com/npm/cmd-shim/pull/43 ) lorsque l'entrée de pipeline a été transmise à le scénario.

Je viens d'installer le dernier NPM sur une nouvelle machine et c'est un comportement très dérangeant alors qu'il fonctionnait hors de la boîte.

La solution fournie par @ RAJU2529 convient tant que vous pouvez faire ce que vous voulez sur votre machine. Sur une machine appartenant à un domaine, ce paramètre peut être piloté par les paramètres de l'organisation et ne peut pas être remplacé, même si l'utilisateur est administrateur sur la machine.
Quelqu'un a-t-il une autre solution de contournement, à l'exception de la rétrogradation de la version NPM?

Supprimer tous les scripts *.ps1 dans le répertoire npm bin?

@ ExE-Boss c'est ce que j'ai fini de faire pour l'instant, mais c'est vraiment une solution de contournement ...

Acceptez également ce qui précède. Mieux que changer votre politique d'exécution ... Je sais que cela fonctionne et que tout le monde est susceptible d'exécuter des scripts mais ... tout simplement complètement idiot

Nous avons récemment mis à jour nos serveurs de construction avec la dernière LTS de node.
Certains de nos scripts PowerShell utilisent du code comme:

Start-Process "npm-cli-login" [...] -NoNewWindow

Si vous demandez à PowerShell quel exécutable il utilise ( (Get-Command npm-cli-login).Source ), vous obtenez les fichiers ps1 nouvellement créés au lieu de cmd .

Le processus se termine avec %1 is not a valid win32 application car un script ps1 n'est pas un exécutable valide.

Il s'agit d'un changement radical dans une version et devrait au moins être revu.

Supprimer tous les scripts *.ps1 dans le répertoire npm bin?

Avons-nous un moyen de forcer Windows à ne pas créer le script .ps1 tout en utilisant npm link ou npm i -g ../<package> ? C'est un peu frustrant de devoir aller dans le dossier npm et de nettoyer ce désordre tout le temps.

Une solution de contournement rapide si votre système dispose d'une invite de commande consiste à indiquer à PowerShell d'utiliser la version cmd à la place: <package-name>.cmd

Par exemple pour TypeScript:
au lieu de
tsc -v qui appelle maintenant tsc.ps1 dans PowerShell
utilisation
tsc.cmd -v

Une solution de contournement rapide si votre système dispose d'une invite de commande consiste à indiquer à PowerShell d'utiliser la version cmd à la place: <package-name>.cmd

Oui, si vous ajoutez .cmd powershell utilise le bon exécutable.

Mais si vous avez des scripts de construction versionnés qui ne devraient pas changer après une version, vous n'avez que deux possibilités:

• Changez-le quand même
• Ne pas mettre à jour le nœud -> problème de sécurité possible.

La demande d'extraction 34 qui a ajouté cette fonctionnalité y fait référence comme un correctif pour le problème npm 20699 . En vérifiant ce problème, il semble que le problème principal soit de passer le caractère esperluette en tant qu'argument de commande sur la ligne de commande Windows. Cela est interprété comme un délimiteur de commande, donc des erreurs.

Cependant, dans la ligne de commande Windows, nous pouvons échapper le caractère esperluette avec un signe d'insertion. ^&

Longshot, mais cela pourrait-il être une solution alternative réalisable à ce qui a été implémenté qui a introduit ces changements décisifs? Existe-t-il un moyen de détecter qu'un argument est destiné à la ligne de commande Windows et à l'expression régulière ou d'injecter le caractère caret dans l'argument comme échappement? Quelqu'un comme le patron de @ ExE-Boss sait-il s'il existe une raison pour laquelle nous n'aurions pas pu résoudre ce problème en utilisant quelque chose de similaire?

Le document suivant décrit la meilleure façon de gérer l'analyse des arguments de ligne de commande Windows. Utilisez-le comme guide?
https://docs.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way

Je pense que les tuyaux ne fonctionnent pas non plus avec les scripts ps1 liés à cela.

J'essaye les outils très utilisés suivants:
prettyjson
plus jolie

Par exemple, lorsque j'exécute ce qui suit sur Powershell:
echo '{"a": 1}' | prettyjson

Le terminal continuera simplement à attendre les entrées jusqu'à ce que CTRL + C soit enfoncé et qu'il sorte sans sortie attendue.

La solution de contournement consiste à ajouter .cmd à la commande ou simplement à utiliser cmd à la place:
echo '{"a": 1}' | prettyjson.cmd

Les sorties

a: 1

Ma question sur stackoverflow: https://stackoverflow.com/questions/62951533/why-pipes-are-not-working-on-powershell-for-various-nodejs-cli-tools

Mettre à jour

Désolé, je viens de rappeler qu'il a été commenté ici avant https://github.com/npm/cli/issues/470#issuecomment -568165144 à propos de la tuyauterie stdin et le PR est ici https://github.com/npm/cmd-shim / tirer / 43 . Mais quand même, utiliser .cmd semble fonctionner pour les tuyaux.