@Cerlancism. digite os seguintes comandos no PowerShell

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

ou

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

depois de executar seu script .ps1 PowerShell

@Cerlancism
Em https://github.com/npm/read-cmd-shim/pull/6 , adiciono apenas o caminho de extração do suporte do PowerShell.
Esta função é para https://github.com/npm/cli/pull/281

Se você quiser saber por que * .ps é adicionado ao instalar o pacote, consulte isto: https://github.com/npm/cmd-shim/pull/34

Os scripts do Node.js ( https://github.com/npm/cmd-shim/pull/43 ) quando a entrada do pipeline é passada para o script.

Acabei de instalar o NPM mais recente em uma máquina nova e isso é um comportamento muito perturbador enquanto costumava funcionar fora da caixa.

A solução fornecida por @ RAJU2529 está bem, desde que você possa fazer o que quiser em sua máquina. Na máquina associada ao domínio, esta configuração pode ser controlada pelas configurações da organização e não pode ser substituída, mesmo se o usuário for administrador na máquina.
Alguém tem outra solução alternativa, exceto desatualizar a versão do NPM?

Excluir todos os scripts *.ps1 do diretório npm bin?

@ ExE-Boss foi o que acabei fazendo por agora, mas é realmente uma solução alternativa ...

Concorde com o acima também. Melhor do que mudar sua política de execução ... Eu sei que funciona e provavelmente todas as pessoas estão executando scripts, mas ... completamente idiota

Recentemente, atualizamos nossos servidores de construção para o último LTS de nó.
Alguns de nossos PowerShell-Scripts usam códigos como:

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

Se você perguntar ao PowerShell qual executável ele usa ( (Get-Command npm-cli-login).Source ), você obterá os arquivos ps1 recém-criados em vez do cmd .

O processo sai com %1 is not a valid win32 application porque um script ps1 não é um executável válido.

Esta é uma alteração importante em uma versão e deve ser pelo menos revisada.

Excluir todos os scripts *.ps1 do diretório npm bin?

Temos uma maneira de forçar o Windows a não criar o script .ps1 ao usar npm link ou npm i -g ../<package> ? É meio frustrante ter que ir na pasta npm e limpar essa bagunça o tempo todo.

Uma solução rápida se o seu sistema tiver Prompt de Comando é dizer ao PowerShell para usar a versão cmd em vez disso: <package-name>.cmd

Por exemplo, para TypeScript:
ao invés de
tsc -v que agora chama tsc.ps1 no PowerShell
usar
tsc.cmd -v

Uma solução rápida se o seu sistema tiver Prompt de Comando é dizer ao PowerShell para usar a versão cmd em vez disso: <package-name>.cmd

Sim, se você adicionar .cmd powershell usa o executável correto.

Mas se você tiver versões de scripts de compilação que não devem mudar após o lançamento, você tem apenas duas possibilidades:

• Mude mesmo assim
• Não atualize o nó -> possível problema de segurança.

A solicitação de pull 34 que adicionou esse recurso faz referência a ele como uma correção para o problema npm 20699 . Verificando esse problema, parece que o problema principal é passar o caractere e comercial como um argumento de comando na linha de comando do Windows. Isso é interpretado como um delimitador de comando, portanto, apresenta erros.

No entanto, na linha de comando do Windows, podemos escapar o caractere e comercial com um circunflexo. ^&

Longshot, mas isso poderia ser uma solução alternativa viável para o que foi implementado que introduziu essas mudanças significativas? Existe alguma maneira de detectar que um argumento é destinado à linha de comando do Windows e regex ou injetar o caractere circunflexo no argumento como um escape? Alguém como o chefe @ ExE-Boss sabe se há algum motivo pelo qual não teríamos resolvido esse problema usando algo semelhante?

O seguinte documento cobre a melhor maneira de lidar com a análise de argumentos da linha de comando do Windows. Use-o como um guia?
https://docs.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way

Acho que os tubos também não estão funcionando usando scripts ps1 relacionados a isso.

Estou experimentando as seguintes ferramentas altamente utilizadas:
Prettyjson
mais bonita

Por exemplo, quando executo o seguinte no Powershell:
echo '{"a": 1}' | prettyjson

O terminal continuará esperando por entradas até que CTRL + C seja pressionado e saia sem nenhuma saída esperada.

A solução alternativa é adicionar .cmd ao comando ou apenas usar cmd em seu lugar:
echo '{"a": 1}' | prettyjson.cmd

Saídas

a: 1

Minha pergunta sobre stackoverflow: https://stackoverflow.com/questions/62951533/why-pipes-are-not-working-on-powershell-for-various-nodejs-cli-tools

Atualizar

Desculpe, acabei de lembrar que foi comentado aqui antes de https://github.com/npm/cli/issues/470#issuecomment -568165144 sobre a tubulação stdin e o PR está aqui https://github.com/npm/cmd-shim / pull / 43 . Mesmo assim, usar .cmd parece funcionar para tubos.