Cette réponse est une tentative de réponse technique plutôt que d'opinion.
Si nous voulons être des puristes POSIX, nous définissons une ligne comme:
Une séquence de zéro ou plusieurs caractères non <nouvelle> plus un caractère <nouvelle> de fin.
Source: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
Une ligne incomplète comme:
Une séquence d'un ou plusieurs caractères non <nouvelle> à la fin du fichier.
Source: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_195
Un fichier texte comme:
Un fichier qui contient des caractères organisés en zéro ou plusieurs lignes. Les lignes ne contiennent pas de caractères NUL et aucune ne peut dépasser {LINE_MAX} octets de longueur, y compris le caractère <newline>. Bien que POSIX.1-2008 ne fasse pas de distinction entre les fichiers texte et les fichiers binaires (voir la norme ISO C), de nombreux utilitaires ne produisent une sortie prévisible ou significative que lorsqu'ils fonctionnent sur des fichiers texte. Les utilitaires standard qui ont de telles restrictions spécifient toujours des "fichiers texte" dans leurs sections STDIN ou INPUT FILES.
Source: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_397
Une chaîne comme:
Une séquence contiguë d'octets terminée par et incluant le premier octet nul.
Source: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_396
De cela, nous pouvons déduire que la seule fois où nous pourrons potentiellement rencontrer un type de problème, c'est si nous traitons le concept d'une ligne de fichier ou d'un fichier comme un fichier texte (étant donné qu'un fichier texte est une organisation de zéro ou plusieurs lignes, et une ligne que nous connaissons doit se terminer par un <newline>).
Exemple: wc -l filename.
Dans le wcmanuel, nous lisons:
Une ligne est définie comme une chaîne de caractères délimitée par un caractère <newline>.
Quelles sont les implications pour les fichiers JavaScript, HTML et CSS étant alors que ce sont des fichiers texte ?
Dans les navigateurs, les IDE modernes et les autres applications frontales, il n'y a aucun problème à ignorer EOL à EOF. Les applications analysent correctement les fichiers. Il doit, puisque tous les systèmes d'exploitation ne sont pas conformes à la norme POSIX, il serait donc impossible pour les outils non OS (par exemple les navigateurs) de gérer les fichiers conformément à la norme POSIX (ou à toute norme de niveau OS).
Par conséquent, nous pouvons être relativement confiants qu'EOL chez EOF n'aura pratiquement aucun impact négatif au niveau de l'application, peu importe s'il s'exécute sur un système d'exploitation UNIX.
À ce stade, nous pouvons affirmer avec certitude que sauter EOL à EOF est sûr lorsque vous traitez avec JS, HTML, CSS côté client. En fait, nous pouvons affirmer que la réduction de l'un de ces fichiers, ne contenant pas de <newline>, est sûre.
Nous pouvons aller un peu plus loin et dire qu'en ce qui concerne NodeJS, il ne peut pas non plus adhérer au standard POSIX étant donné qu'il peut fonctionner dans des environnements non conformes à POSIX.
Que nous reste-t-il alors? Outillage au niveau du système.
Cela signifie que les seuls problèmes qui peuvent survenir concernent les outils qui s'efforcent d'adhérer leurs fonctionnalités à la sémantique de POSIX (par exemple, la définition d'une ligne comme indiqué dans wc).
Même ainsi, tous les shells n'adhéreront pas automatiquement à POSIX. Par exemple, Bash n'a pas par défaut le comportement POSIX. Il y a un interrupteur pour lui permettre: POSIXLY_CORRECT.
Matière à réflexion sur la valeur de l'EOL étant <newline>: https://www.rfc-editor.org/old/EOLstory.txt
En restant sur la piste de l'outillage, à toutes fins pratiques, considérons ceci:
Travaillons avec un fichier qui n'a pas de fin de vie. À ce jour, le fichier dans cet exemple est un JavaScript minifié sans EOL.
curl http://cdnjs.cloudflare.com/ajax/libs/AniJS/0.5.0/anijs-min.js -o x.js
curl http://cdnjs.cloudflare.com/ajax/libs/AniJS/0.5.0/anijs-min.js -o y.js
$ cat x.js y.js > z.js
-rw-r--r-- 1 milanadamovsky 7905 Aug 14 23:17 x.js
-rw-r--r-- 1 milanadamovsky 7905 Aug 14 23:17 y.js
-rw-r--r-- 1 milanadamovsky 15810 Aug 14 23:18 z.js
Notez que la cattaille du fichier est exactement la somme de ses parties individuelles. Si la concaténation des fichiers JavaScript est une préoccupation pour les fichiers JS, la préoccupation la plus appropriée serait de démarrer chaque fichier JavaScript avec un point-virgule.
Comme quelqu'un d'autre l'a mentionné dans ce fil: que faire si vous voulez catdeux fichiers dont la sortie ne devient qu'une ligne au lieu de deux? En d'autres termes, catfait ce qu'il est censé faire.
Le mande catne mentionne que la lecture des entrées jusqu'à EOF, pas <newline>. Notez que le -nbasculement de catimprimera également une ligne non terminée (nouvelle ligne) (ou ligne incomplète ) en tant que ligne - étant donné que le décompte commence à 1 (selon le man.)
-n Numéroter les lignes de sortie, en commençant à 1.
Maintenant que nous comprenons comment POSIX définit une ligne , ce comportement devient ambigu, ou vraiment non conforme.
La compréhension de l'objectif et de la conformité d'un outil donné aidera à déterminer à quel point il est essentiel de terminer les fichiers avec une fin de vie. En C, C ++, Java (JAR), etc ... certaines normes imposent une nouvelle ligne pour la validité - aucune norme de ce type n'existe pour JS, HTML, CSS.
Par exemple, au lieu d'en utiliser wc -l filenameun, vous pouvez le faire awk '{x++}END{ print x}' filename, et soyez assuré que le succès de la tâche n'est pas compromis par un fichier que nous pourrions vouloir traiter que nous n'avons pas écrit (par exemple une bibliothèque tierce telle que le JS minifié que nous avons curl) - à moins que notre l'intention était vraiment de compter les lignes au sens conforme POSIX.
Conclusion
Il y aura très peu de cas d'utilisation réels où sauter EOL à EOF pour certains fichiers texte tels que JS, HTML et CSS aura un impact négatif - voire pas du tout. Si nous comptons sur la présence de <newline>, nous limitons la fiabilité de nos outils uniquement aux fichiers que nous créons et nous nous exposons aux erreurs potentielles introduites par des fichiers tiers.
Morale de l'histoire: des outils d'ingénieur qui n'ont pas la faiblesse de s'appuyer sur EOL chez EOF.
N'hésitez pas à publier des cas d'utilisation tels qu'ils s'appliquent à JS, HTML et CSS où nous pouvons examiner comment le fait de sauter EOL a un effet négatif.