Je ne sais pas pour vous, mais j'aime que les journaux de ma console dans mes projets JavaScript soient beaux. Et comme tous les terminaux ne prennent pas en charge les emojis, quel meilleur moyen que de colorer la sortie de la console ?

Eh bien, vous pouvez procéder en recherchant sur Google le code d'échappement ANSI pour chaque style de console souhaité. Ou peut-être en mémoriser certains à partir d'une page comme W3Docs. Mais j'aime donner une belle apparence à mes journaux, je ne suis certainement pas une personne capable de mémoriser beaucoup de choses et j'aime avoir une méthode qui fonctionne partout.

Eh bien, je n'utilise généralement que des journaux colorés pour JS, donc pas besoin de quelque chose qui fonctionne littéralement partout. Mais au moins quelque chose qui fonctionne partout où JavaScript est impliqué.

J'ai donc décidé d'écrire mon propre script contenant tous les codes d'échappement ANSI possibles dont je pourrais avoir besoin, sous forme de fonctions. Mais ensuite j’ai réalisé qu’il serait ennuyeux de copier encore et encore le même script dans tous mes projets. Ainsi, en tant que personne n'ayant jamais travaillé avec une commande npm autre que npm i et init, j'ai décidé d'en savoir plus et de créer un package NPM privé que je pourrais simplement installer dans mes projets (ou cloner son référentiel GitHub pour les projets non NodeJS).
Je ne voulais pas gérer l'authentification NPM à chaque fois que j'installais le package, alors je l'ai simplement rendu public.

Et c'est pour cela que nous sommes ici aujourd'hui : javascript-console-styling est un package que j'ai créé pour me faciliter ce processus.

En effet, des packages similaires au mien ont déjà été réalisés (ce que je n'avais réalisé qu'après l'avoir réalisé). Mais j'ai remarqué que ma propre solution était encore meilleure pour moi, ou pour n'importe qui comme moi :

• Mon package n'occupait que 14 Ko d'espace, selon npm. Alors que d'autres packages similaires prenaient jusqu'à 50 fois la même quantité (plus de 500 kilo-octets). Même s'ils font tous les deux moins d'un mégaoctet, il est toujours préférable d'avoir un package plus petit car vous pouvez gérer tous ses fichiers facilement (ou même le bifurquer et le modifier facilement si vous le souhaitez)

• Mon package pourrait imbriquer différents styles et décorations puisqu'il s'agit de fonctions... Et même si vous avez une chaîne stylisée entière qui contient une sous-chaîne avec un style différent, vous pouvez simplement concaténer la sous-chaîne (y compris la sous-chaîne à l'intérieur la chaîne parent empêchera tous les styles de s'appliquer après elle en raison de la réinitialisation effectuée par chaque fonction de style)

• Mon package disposait d'outils de test simples qui montraient toutes les combinaisons possibles de couleurs et de décorations afin que les utilisateurs puissent vérifier sa sortie dans leur terminal (les fonctions de test ne sont pas incluses dans le package par défaut, mais sont disponibles sur la page NPM et sur GitHub)

Donc dans l’ensemble, je préfère utiliser mon propre code. Mais posséder un package public implique notamment de s'assurer que les gens sachent comment cela peut les aider, afin qu'ils puissent choisir eux-mêmes s'ils en ont besoin.

Je ne pense pas que ce sera le dernier package NPM que je créerai, mais c'était un bon moyen de me motiver pour tout ce qui concerne le NPM !

Assurez-vous de consulter le package et bon piratage !