What is the problem this feature will solve?
Line endings of the npm and other bash scripts are CRLF (\r\n) instead of LF (\n) in the Windows installation of the node.
Git Bash
hrkad@HRK-HPZBOOK MINGW64 /c/Program Files/nodejs
$ \ls -alFh
total 62M
drwxr----- 1 hrkad 197610 0 Jul 16 19:50 ./
drwxr----- 1 hrkad 197610 0 Jul 16 16:46 ../
-rwxr----- 1 hrkad 197610 334 Jul 8 06:00 corepack*
-rw-r----- 1 hrkad 197610 218 Jul 8 06:00 corepack.cmd
-rw-r----- 1 hrkad 197610 3.0K Jul 8 06:00 install_tools.bat
-rwxr----- 1 hrkad 197610 62M Jul 13 14:32 node.exe*
-rw-r----- 1 hrkad 197610 8.8K Oct 14 2021 node_etw_provider.man
drwxr----- 1 hrkad 197610 0 Jul 16 16:34 node_modules/
-rw-r----- 1 hrkad 197610 702 Oct 14 2021 nodevars.bat
-rwxr----- 1 hrkad 197610 1.4K Jul 16 19:50 npm*
-rw-r----- 1 hrkad 197610 483 Jul 7 06:00 npm.cmd
-rwxr----- 1 hrkad 197610 1.6K Jul 7 06:00 npx*
-rw-r----- 1 hrkad 197610 539 Jul 7 06:00 npx.cmd
hrkad@HRK-HPZBOOK MINGW64 /c/Program Files/nodejs
$ cat -v npm | head -1
#!/usr/bin/env bash^M
hrkad@HRK-HPZBOOK MINGW64 /c/Program Files/nodejs
$ cat -v npx | head -1
#!/usr/bin/env bash^M
hrkad@HRK-HPZBOOK MINGW64 /c/Program Files/nodejs
$ cat -v corepack | head -1
#!/bin/sh^M
This causes npm scripts unable to use on WSL distros like Ubuntu.
WSL Ubuntu 22.04 LTS
hrk@HRK-HPZBOOK:.../Program Files/nodejs$ pwd
/mnt/c/Program Files/nodejs
hrk@HRK-HPZBOOK:.../Program Files/nodejs$ npm --version
/usr/bin/env: ‘bash\r’: No such file or directory
hrk@HRK-HPZBOOK:.../Program Files/nodejs$ npx --version
/usr/bin/env: ‘bash\r’: No such file or directory
hrk@HRK-HPZBOOK:.../Program Files/nodejs$ corepack --version
-bash: /mnt/c/Program Files/nodejs/corepack: /bin/sh^M: bad interpreter: No such file or directory
On Git Bash, the npm scripts with CRLF endings are interpreted without an issue.
Git Bash
hrkad@HRK-HPZBOOK MINGW64 /c/Program Files/nodejs
$ npm --version
8.14.0
hrkad@HRK-HPZBOOK MINGW64 /c/Program Files/nodejs
$ npx --version
8.14.0
hrkad@HRK-HPZBOOK MINGW64 /c/Program Files/nodejs
$ corepack --version
0.12.0
What is the feature you are proposing to solve the problem?
Line endings of the npm and other bash scripts should be LF (\n) instead of CRLF (\r\n) in the Windows installation of the node.
What alternatives have you considered?
Using dos2unix.exe from Git Bash solves the issue.
Git Bash
hrkad@HRK-HPZBOOK MINGW64 /c/Program Files/nodejs
$ dos2unix.exe npm
dos2unix: converting file npm to Unix format...
hrkad@HRK-HPZBOOK MINGW64 /c/Program Files/nodejs
$ dos2unix.exe npx
dos2unix: converting file npx to Unix format...
hrkad@HRK-HPZBOOK MINGW64 /c/Program Files/nodejs
$ dos2unix.exe corepack
dos2unix: converting file corepack to Unix format...
WSL Ubuntu 22.04 LTS
hrk@HRK-HPZBOOK:.../Program Files/nodejs$ npm --version
8.14.0
hrk@HRK-HPZBOOK:.../Program Files/nodejs$ npx --version
8.14.0
hrk@HRK-HPZBOOK:.../Program Files/nodejs$ corepack --version
/mnt/c/Program Files/nodejs/corepack: 11: exec: node: not found
Although, corepack --version in the above session fails due to another issue of missing node shim script pointing to node.exe
Other alternatives to installing node natively on WSL obviously solve the issue but it causes double dependencies of the core software and global packages, one on Windows and the other inside WSL.
What is the problem this feature will solve?
Line endings of the npm and other bash scripts are CRLF (\r\n) instead of LF (\n) in the Windows installation of the node.
Git Bash
This causes npm scripts unable to use on WSL distros like Ubuntu.
WSL Ubuntu 22.04 LTS
On Git Bash, the npm scripts with CRLF endings are interpreted without an issue.
Git Bash
What is the feature you are proposing to solve the problem?
Line endings of the npm and other bash scripts should be LF (\n) instead of CRLF (\r\n) in the Windows installation of the node.
What alternatives have you considered?
Using dos2unix.exe from Git Bash solves the issue.
Git Bash
WSL Ubuntu 22.04 LTS
Although,
corepack --versionin the above session fails due to another issue of missing node shim script pointing to node.exeOther alternatives to installing node natively on WSL obviously solve the issue but it causes double dependencies of the core software and global packages, one on Windows and the other inside WSL.