@Cerlancismo. escriba los siguientes comandos en powershell

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

o

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

después de ejecutar su script .ps1 PowerShell

@Cerlancismo
En https://github.com/npm/read-cmd-shim/pull/6 , solo agrego la ruta de extracción del soporte de PowerShell.
Esta función es para https://github.com/npm/cli/pull/281

Si desea saber por qué se agrega * .ps al instalar el paquete, consulte esto: https://github.com/npm/cmd-shim/pull/34

Los scripts de Node.js ( https://github.com/npm/cmd-shim/pull/43 ) cuando la entrada de la canalización se ha pasado a la secuencia de comandos.

Acabo de instalar el último NPM en una máquina nueva y este es un comportamiento muy perturbador mientras solía funcionar fuera de la caja.

La solución proporcionada por @ RAJU2529 está bien siempre que pueda hacer lo que quiera en su máquina. En una máquina unida a un dominio, esta configuración puede regirse por la configuración de la organización y no se puede anular, incluso si el usuario es el administrador de la máquina.
¿Alguien tiene otra solución alternativa, excepto rebajar la versión de NPM?

¿Eliminar todos los scripts *.ps1 en el directorio bin de npm ?

@ ExE-Boss eso es lo que terminé haciendo por ahora, pero realmente es una solución ...

Acepte lo anterior también. Mejor que cambiar su política de ejecución ... sé que funciona y es probable que todos y todas las personas estén ejecutando scripts, pero ... simplemente una tontería

Recientemente actualizamos nuestros servidores de compilación a la última versión de LTS de node.
Algunos de nuestros PowerShell-Scripts usan código como:

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

Si le pregunta a powershell qué ejecutable usa ( (Get-Command npm-cli-login).Source ) obtendrá los archivos ps1 recién creados en lugar del cmd .

El proceso finaliza con %1 is not a valid win32 application porque un script ps1 no es un ejecutable válido.

Este es un cambio importante dentro de una versión y al menos debería revisarse.

¿Eliminar todos los scripts *.ps1 en el directorio bin de npm ?

¿Tenemos alguna forma de obligar a Windows a no crear el script .ps1 mientras usamos npm link o npm i -g ../<package> ? Es un poco frustrante tener que ir a la carpeta npm y limpiar este desorden todo el tiempo.

Una solución rápida si su sistema tiene Símbolo del sistema es decirle a PowerShell que use la versión cmd en su lugar: <package-name>.cmd

Por ejemplo, para TypeScript:
en vez de
tsc -v que ahora llama a tsc.ps1 en PowerShell
utilizar
tsc.cmd -v

Una solución rápida si su sistema tiene Símbolo del sistema es decirle a PowerShell que use la versión cmd en su lugar: <package-name>.cmd

Sí, si agrega .cmd powershell usa el ejecutable correcto.

Pero si ha versionado scripts de compilación que no deberían cambiar después de un lanzamiento, solo tiene dos posibilidades:

• Cámbialo de todos modos
• No actualice el nodo -> posible problema de seguridad.

La solicitud de extracción 34 que agregó esta función hace referencia a ella como una solución para el problema npm 20699 . Al verificar ese problema, parece que el problema principal es pasar el carácter ampersand como un argumento de comando en la línea de comando de Windows. Eso se interpreta como un delimitador de comandos, por lo que genera errores.

Sin embargo, en la línea de comandos de Windows, podemos escapar del carácter comercial con un signo de intercalación. ^&

Longshot, pero ¿podría ser esta una solución alternativa viable a lo que estaba implícito que introdujo estos cambios importantes? ¿Hay alguna forma de que podamos detectar que un argumento está destinado a la línea de comandos de Windows y la expresión regular o inyectar el carácter de intercalación en el argumento como escape? ¿Alguien como @ ExE-Boss boss sabe si hay alguna razón por la que no podríamos haber abordado este problema con algo similar?

El siguiente documento cubre la mejor manera de manejar el análisis de argumentos de la línea de comandos de Windows. ¿Usarlo como guía?
https://docs.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way

Creo que las tuberías tampoco funcionan con scripts de ps1 relacionados con esto.

Estoy probando las siguientes herramientas muy utilizadas:
prettyjson
mas linda

Por ejemplo, cuando ejecuto lo siguiente en Powershell:
echo '{"a": 1}' | prettyjson

El terminal simplemente seguirá esperando las entradas hasta que presione CTRL + C y saldrá sin una salida esperada.

La solución es agregar .cmd al comando o simplemente usar cmd en su lugar:
echo '{"a": 1}' | prettyjson.cmd

Salidas

a: 1

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

Actualizar

Lo siento, acabo de recordar que se comentó aquí antes https://github.com/npm/cli/issues/470#issuecomment -568165144 sobre tuberías stdin y el PR está aquí https://github.com/npm/cmd-shim / tirar / 43 . Pero aún así, el uso de .cmd parece funcionar para tuberías.