Add step to verify Node.js + npm + Corepack installation to avoid "command not found" error

[karlhorky]

Running any of the Corepack commands eg. corepack enable or corepack prepare pnpm@latest --activate can sometimes cause a "not found" message:

Example on macOS

$ corepack prepare pnpm@latest --activate
zsh: command not found: corepack

---

Example on Windows

PS C:\Windows\system32> corepack enable
corepack : Die Benennung "corepack" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.

TODO

• [ ] Research when and why this occurs
• [ ] Add a step (or instruction as part of an existing step) to the guides to check for successful installation
  • [ ] Windows
  • [ ] macOS
  • [ ] Linux

[Boris1605]

after running those commands in the terminal to upgrade node latest

brew upgrade node@20
corepack disable
corepack enable
corepack prepare pnpm@latest --activate

i have the same problem now that it shows:

Warning: node@20 20.11.1 already installed
zsh: command not found: corepack
zsh: command not found: corepack
zsh: command not found: corepack

[karlhorky]

It seems like this can happen after upgrading Node.js via commands like brew upgrade node@20.

In that case, we needed to also run:

brew link --overwrite node@20

Added to upgrade cheatsheet:

• https://github.com/upleveled/system-setup/commit/c2e412463d1d18df28969512fb4eb46184b980d2

[karlhorky]

@ProchaLu on Windows it appears that this may sometimes be caused on some Windows machines by an execution policy of Restricted (the following was on a Windows 10 machine):

PS C:\Windows\system32> corepack enable
corepack : Die Benennung "corepack" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.

PS C: \Windows\system32> Get-ExecutionPolicy - List
        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy Undefined
UserPolicy    Undefined
Process       Undefined
CurrentUser   Undefined
LocalMachine  Undefined

PS C: \Windows\system32> Get-ExecutionPolicy
Restricted

PS C: \Windows\system32> Set-ExecutionPolicy RemoteSigned
Ausführungsrichtlinie ändern
Die Ausführungsrichtlinie trägt zum Schutz vor nicht vertrauenswürdigen Skripts bei. Wenn Sie die Ausführungsrichtlinie
andern,
sind Sie möglicherweise den im Hilfethema
"about_Execution_Policies" unter
"https:/go.microsoft.com/fwlink/?LinkID=135170™ beschriebenen Sicherheitsrisiken ausgesetzt. Möchten Sie die
Ausführungsrichtlinie ändern?
[0] Ja
[A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist "N"): J

PS C:\Windows\system32> Get-ExecutionPolicy
RemoteSigned

PS C: \Windows\system32> corepack enable
PS C: \Windows\system32> corepack prepare popm@latest --activate
Preparing prpm@latest for immediate activation...

Enabling the RemoteSigned execution policy with Set-ExecutionPolicy RemoteSigned allowed this student with this Windows 10 machine to proceed and use corepack

Before we can change the guide, this needs further research as to:

1. why this execution policy is how it is
2. what best practice is for execution policies
3. and why all other systems have not needed this so far

[ProchaLu]

Windows

PowerShell's execution policy is a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts. This feature helps prevent the execution of malicious scripts. The default execution policy for Windows client computers is Restricted. This setting prevents running all script files.

To allow PowerShell to run scripts, we need to change the setting to RemoteSigned, that is the default policy for Windows server computers. This setting allows:

• Scripts can run
• Requires a digital signature from a trusted publisher on scripts and configuration files that are downloaded from the internet which includes email and instant messaging programs
• Doesn't require digital signatures on scripts that are written on the local computer and not downloaded from the internet

[karlhorky]

we still need some kind of first explanation / investigation for this:

3. and why all other systems have not needed this so far

I edited the comment above to remove the bit about speculation, which didn't add anything to the discussion

let's confirm that specific thing. the only two bits of information at PowerShell's execution policy linked above are:

Restricted

• The default execution policy for Windows client computers.

Default

• Restricted for Windows clients.

1. are we sure this actually applies to what we're talking about here? let's try to find other resources that corroborate this
2. we need to confirm the behavior: when a new Windows Home / Pro installation is set up, what is the default? if we can confirm that the default is Restricted, then we can continue to any suggestions that you have for a solution

[ProchaLu]

When installing Windows for the first time, Windows 10/11 uses Windows PowerShell 5.1. as default. The default execution policy for Windows 10/11 is Restricted, also explained in these different blog posts:

• https://www.hanselman.com/blog/signing-powershell-scripts
• https://www.ninjaone.com/blog/understanding-powershell-execution-policies/
• https://www.mssqltips.com/sqlservertip/2702/setting-the-powershell-execution-policy/
• https://www.elevenforum.com/t/change-powershell-script-execution-policy-in-windows-11.12879/

I think this confirms the default behavior. If we don't want to change it, we could change the execution policy for the single pnpm setup command because we do the same already when installing Chocolatey.

Set-ExecutionPolicy Bypass -Scope Process -Force;

[karlhorky]

If we don't want to change it, we could change the execution policy for the single pnpm setup command because we do the same already when installing Chocolatey.

this sounds like the best, most secure option, but I think the UX would have a downside here, because it would be required for every time a student installs a new version of pnpm with corepack, right?

[ProchaLu]

this sounds like the best, most secure option, but I think the UX would have a downside here, because it would be required for every time a student installs a new version of pnpm with corepack, right?

Yes, students always have to set the execution policy when running pnpm with corepack.

Maybe a different solution would be to set the execution policy to AllSigned. In the install guide of the Chocolatey docs, we are currently using this install command

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

This command sets the execution policy to Bypass for this single command. As an alternative, the Chocolatey docs suggest changing the execution policy to AllSigned. AllSigned requires that all scripts and configuration files are signed by a trusted publisher, including scripts written on the local computer.

The script to install Chocolatey would be:

Set-ExecutionPolicy AllSigned; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

When changing the execution policy in this step, we don't have to make additional changes to the System Setup Guide.

[karlhorky]

When changing the execution policy in this step, we don't have to make additional changes to the System Setup Guide.

nice, sounds like a secure option, and we don't need to add a new step 👍