[QUESTION] Necessity of Powershell Script Support for Global Packages

[Cerlancism]

What / Why

As per npm/read-cmd-shim#6 adds PowerShell Scripts when installing global packages. It causes some hassle on Windows needing to add a security flag to run ps1 script, else it gets this error

****.ps1 cannot be loaded because running scripts is disabled on this system

Previously, all global npm packages run out of box as PowerShell would use the cmd script instead. I foresee with this addition it will cause many confusion among people, especially ones who are using the built-in terminal of Visual Studio Code on Windows, which is PowerShell.

References

microsoft/TypeScript#35031
https://stackoverflow.com/questions/58796490/tsc-ps1-cannot-be-loaded-because-running-scripts-is-disabled-on-this-system
And the following some newer answers even suggest deleting the ps1 file.
https://stackoverflow.com/questions/57673913/vsc-powershell-after-npm-updating-packages-ps1-cannot-be-loaded-because-runnin

[RAJU2529]

@Cerlancism. type the following commands in powershell

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

or

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

after run your .ps1 PowerShell script

[suiyun39]

@Cerlancism
In npm/read-cmd-shim#6 , I only add extract path from powershell support.
This function is for #281

If you want to know why is *.ps added when install package, please see this: npm/cmd-shim#34

[ExE-Boss]

PowerShell scripts are also the only ones which provide a built‑in way to pipe stdin through into the Node.js process (npm/cmd-shim#43) when pipeline input has been passed to the script.

[ggirard07]

Just installed latest NPM on a fresh machine and this is very disturbing behavior while it used to work out of the box.

Solution provided by @RAJU2529 is fine as long as you can do whatever you want on your machine. On domain-joined machine, this setting can be driven by organization settings and cannot be overridden, even if the user is admin on the machine.
Does anyone have another workaround, except downgrading NPM version?

[ExE-Boss]

Delete all *.ps1 scripts in the npm bin directory?

[ggirard07]

@ExE-Boss that's what I ended doing for now, but it really is a workaround...

[Perustaja]

Agree to the above too. Better than changing your execution policy...I know it works and all and people are likely to be running scripts but...just completely silly

[acuntex]

We recently updated our build servers to the latest LTS of node.
Some of our PowerShell-Scripts use code like:

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

If you ask powershell which executable it uses ((Get-Command npm-cli-login).Source) you get the newly created ps1-Files instead of the cmd.

The process exits with %1 is not a valid win32 application because a ps1-script is no valid executable.

This is a breaking change within a version and should be at least reviewed.

[Nanyx]

Delete all *.ps1 scripts in the npm bin directory?

Do we have a way to force Windows to not create the .ps1 script while using npm link or npm i -g ../<package> ? It is kinda frustrating to have to go on the npm folder and clean this mess all the time.

[Cerlancism]

One quick workaround if your system has Command Prompt is to tell PowerShell to use the cmd version instead: <package-name>.cmd

For example for TypeScript:
instead of
tsc -v which now calls tsc.ps1 in PowerShell
use
tsc.cmd -v

[acuntex]

One quick workaround if your system has Command Prompt is to tell PowerShell to use the cmd version instead: <package-name>.cmd

Yes, if you add .cmd powershell uses the correct executable.

But if you have versioned build scripts that should not change after a release, you have only two possibilities:

• Change it anyway
• Don't update node -> possible security problem.

[TroyWitthoeft]

The pull request 34 which added this feature references it as a fix for npm issue 20699. Checking that issue, it seems like the core problem is passing the ampersand character as a command argument on the windows command line. That is interpreted as a command delimiter so it errors.

However, in windows command line, we can escape the ampersand character with a caret. ^&

Longshot, but could this be a feasible alternative solution to what was implmented that introduced these breaking changes? Is there some way we could detect that an argument is destined for the windows command line and regex or inject the caret character into the argument as an escape? Does anyone like @ExE-Boss boss know if there some reason we couldn't have addressed this issue using something similar?

The following document covers the best way to handle windows command line argument parsing. Use it as a guide?
https://docs.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way

[Cerlancism]

I think pipes are also not working using ps1 scripts related to this.

I am trying around the following highly used tools:
prettyjson
prettier

For example when I run the following on Powershell:
echo '{"a": 1}' | prettyjson

The terminal will just keep waiting for inputs till CTRL+C pressed and it exits with no expected output.

The workaround is to add .cmd to the command or just use cmd instead:
echo '{"a": 1}' | prettyjson.cmd

Outputs

a: 1

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

Update

Sorry, I just recalled it was commented here before #470 (comment) about stdin piping and the PR is here npm/cmd-shim#43 . But still, using .cmd seems to work for pipes.

[dlgombert]

It's hilarious that deleting the ps1 file in the node directory is still the only fix. Has there been any progress here?

For reference the tools that were failing for me were 'fx' and 'json'. Lots of JSON tools?

[Cerlancism]

Since I think is probably only a Windows specific issue, it can be fixed by doing the Windows way. My idea is to let the NodeJS installer to inform the limitation of Powershell or possibly set the settings required (Set-ExecutionPolicy -ExecutionPolicy RemoteSigned) for ps1 files to run.

[catchmareck]

Seems like the "proper support" for PowerShell actually made it impossible to run scripts without workarounds. Are there plans to fix it? Having to work around it for every globally installed package or having to globally reduce security settings is quite hilarious.

Workarounds that worked for me:

• use npx to run the commands, ex. npx ng new
• reduce security settings in PowerShell: Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
• delete all the *.ps1 files from the NPM binary folder
• run the commands adding .cmd at the end, ex. ng.cmd new

[darcyclarke]

npm v6 is no longer in active development; We will continue to push security releases to v6 at our team's discretion as-per our Support Policy.

If your bug is preproducible on v7, please re-file this issue using our new issue template.

If your issue was a feature request, please consider opening a new RRFC or RFC. If your issue was a question or other idea that was not CLI-specific, consider opening a discussion on our feedback repo

Closing: This is an automated message.

[ivanes285]

Estaba probando con Set-ExecutionPolicy -ExecutionPolicy RemoteSigned pero no funcionó .
y al final me funciono con este Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

[WarlockD]

Same happens on version 7.24 but lets be clear here. You don't want installs of normal windows 10 allowing full PowerShell unsigned script access. You can alias COM's, install root kits, etc. If your going to run it do it like above with -Scope with current user or localmachine. As my teacher said day one of college, "Security begins with 'Hello World'!"