-
Notifications
You must be signed in to change notification settings - Fork 3k
bin scripts should always have Unix line endings #12371
Comments
NPM publishes files without converting line endings. Files in the bin directory are supposed to be run directly by the shell, and if they contain Windows line endings then macOS fails to interpret the hash-bang correctly. There's an open issue in the NPM repo regarding this (npm/npm#12371).
Just add Also make sure that dos2unix is added to the dev dependencies (npm install --saveDev dos2unix). Note: |
dos2unix doesn't offer a CLI, so that won't work. What does work however is the tool mentioned here: #2097 (comment) To do the one-way conversion that you seem to describe, one would simply have to do:
If one wants to convert back to CRLF after publishing, to get the "Git for Windows" behavior (see: #2097 (comment)), one would need to use some dirty hacks to ensure that it doesn't break anything on non-Windows machines (i.e. line endings should be/stay LF on e.g. Mac and publishing shouldn't fail due to using IF to detect whether the OS is Windows):
It's not pretty but by failing silently on anything that isn't Windows (unless one runs it in some weird bash that maybe doesn't know "true ||" or that does understand "IF"), it avoids having to e.g. create a separate script that does OS checking and that one would need to include in every single package. |
The fix for this issue unfortunately caused a new one #19151 |
Is there any new solution to solve the publish problem besides using We are experiencing the original problem descriped here #2097 with .githook files being generated by a yeoman generator |
See #2097 for context and discussion. When publishing from Windows, depending on how developers set up Git, it's possible that binary scripts will end up in the tarball with
CR LF
line endings, instead of theLF
expected by Unix / OS X. This can cause failures when those scripts are invoked. The logic that Git applies to figure out whether a file is binary or not is surprisingly subtle, and this is the sort of thing that can cause really hard to debug issues if not handled correctly. This is the heuristic @iarna and I have come up with for figuring out which files need their line endings cleaned up:bin
?cannot perform relative import from bin #2 is necessary in the case in which
bin
links to a native binary, which we don't want to mangle during the publish or installation processes.To be a complete solution, this would need to be some kind of stream transform that gets applied at both publish and install time – publish, so that newly-published packages have the correct line endings, and install, so that non-Windows users running installs with the fixed version of the CLI aren't bitten by legacy packages with the wrong line endings in their scripts.
The text was updated successfully, but these errors were encountered: