poor mans t sql formatter npm cli
1.0.0
Un formateur SQL en ligne de commande qui s'exécute dans à peu près n'importe quel environnement (à condition que node.js soit installé).
Il est basé sur le package NPM Poor Man's T-SQL Formatter (poor-mans-t-sql-formatter), qui à son tour est basé sur la bibliothèque C# du même nom ( https://github.com/TaoK/PoorMansTSqlFormatter ).
Ce formateur devrait avoir des fonctionnalités équivalentes au formateur de ligne de commande C# qui existe depuis quelques années (téléchargeable sur http://architectshack.com/PoorMansTSqlFormatter.ashx), avec deux différences majeures :
C'est très facile à installer, surtout dans les environnements Unixey - tant que Node.js est disponible
C'est un peu plus lent que le formateur basé sur .Net.
(en supposant que node.js soit installé)
npm install --global poor-mans-t-sql-formatter-cli
Entrée canalisée/stdin et sortie stdout :
echo "select a from b join c on b.id = c.id where abc = 123 and def = N'whatêver' " | sqlformat
entrée et sortie de fichier :
echo "with a as (select 1 as b) select * from a cros join c" > testfile.sql sqlformat -f testfile.sql -g testfile.sql cat testfile.sql
Ce formateur de ligne de commande se terminera avec un code de sortie différent de 0 si l'analyse SQL « rencontre des problèmes » - par exemple s'il rencontre une instruction « IF » inachevée, suggérant que quelque chose à propos du SQL n'a pas été correctement compris/analysé, et peut donc « se tromper ». Il existe une option pour désactiver ce comportement si le SQL est connu pour être douteux ou si la confusion d'analyse est connue pour être inoffensive.
Si l'analyse est interrompue, tout "fichier de sortie" spécifié restera intact.
Options spécifiques à l'utilitaire de ligne de commande :
| Option | Description | Taper | Défaut |
|---|---|---|---|
| --inputFichier | Lire l'entrée à formater à partir d'un fichier plutôt que de stdin (entrée saisie ou redirigée) | chaîne | |
| --fichiersortie | Écrivez la sortie formatée dans un fichier - comme la redirection shell de la sortie standard, sauf en cas d'erreur, cela laisse le fichier intact | chaîne | |
| --ignoreErreurs | Renvoie le code de sortie 0 (succès) même si l'analyse a échoué (et donc la sortie formatée est suspecte) | bouffon | |
| --inputEncoding | Utilisez un codage de caractères spécifique pris en charge par le nœud pour la saisie - essentiellement utf-16le ou utf-8 | chaîne | utf-8 |
| --outputEncodage | Utilisez un codage de caractères spécifique pris en charge par le nœud pour la sortie - essentiellement utf-16le ou utf-8 | chaîne | utf-8 |
| --forceOutputBOM | Ajouter une marque d'ordre d'octet (BOM) au début de la sortie | bouffon |
Options du formateur standard :
(veuillez noter que les options booléennes qui sont normalement par défaut "true" dans la bibliothèque ont été inversées avec un préfixe "no", conformément aux conventions des paramètres de ligne de commande Unixey)
| Option | Description | Taper | Défaut |
|---|---|---|---|
| --retrait | L'unité d'indentation - généralement une tabulation (t) ou un certain nombre d'espaces | chaîne | t |
| --maxLineWidth | Demander au formateur d'envelopper les lignes longues pour éviter de dépasser cette longueur de ligne | int | 999 |
| --spacesParTab | Ceci est utilisé pour mesurer la longueur de ligne et ne s'applique que si vous utilisez des onglets | int | 4 |
| --statementBreaks | Combien de sauts de ligne doivent être ajoutés lors du démarrage d’une nouvelle instruction ? | int | 2 |
| --clauseBreaks | Combien de sauts de ligne doivent être ajoutés lors du démarrage d’une nouvelle clause dans une instruction ? | int | 1 |
| --no-expandCommaLists | Les listes délimitées par des virgules (colonnes, arguments groupés, etc.) doivent-elles être réparties sur de nouvelles lignes ? | bouffon | |
| --no-trailingCommas | Lorsque vous commencez une nouvelle ligne à cause d'une virgule, la virgule doit-elle être à la fin de la ligne (VS le début de la suivante) ? | bouffon | |
| --spaceAfterExpanedComma | Faut-il ajouter un espace après la virgule ? (généralement pas s'ils sont "à la traîne") | bouffon | |
| --no-expandBooleanExpressions | Les opérateurs booléens (AND, OR) doivent-ils provoquer un saut de ligne ? | bouffon | |
| --no-expandCaseStatements | Les expressions CASE doivent-elles avoir leurs expressions QUAND et ALORS être réparties sur de nouvelles lignes ? | bouffon | |
| --no-expandBetweenConditions | L'argument max des expressions BETWEEN doit-il être réparti sur une nouvelle ligne ? | bouffon | |
| --expandInListes | Les listes IN() doivent-elles avoir chaque argument sur une nouvelle ligne ? | bouffon | |
| --breakJoinOnSections | La section ON d'une clause JOIN doit-elle être répartie sur sa propre ligne ? | bouffon | |
| --no-uppercaseKeywords | Les mots-clés T-SQL (comme SELECT, FROM) doivent-ils être automatiquement mis en majuscule ? | bouffon | |
| --keywordStandardisation | Les mots-clés T-SQL moins courants devraient-ils être remplacés par leurs équivalents standards ? (REMARQUE : uniquement sans danger pour T-SQL !) | bouffon |
Options du formateur d'obscurcissement (commande "min") :
| Option | Description | Taper | Défaut |
|---|---|---|---|
| --randomizeKeywordCase | La casse des mots-clés doit-elle être randomisée, pour minimiser la lisibilité ? | bouffon | |
| --randomizeLineLengths | Le SQL doit-il être encapsulé à intervalles arbitraires, pour minimiser la lisibilité ? | bouffon | |
| --no-preserveComments | Les commentaires dans le code doivent-ils être conservés (au lieu d'être supprimés) ? | bouffon | |
| --enableKeywordSubstitution | Les mots-clés avec des synonymes devraient-ils utiliser des formes moins courantes ? (REMARQUE : uniquement sans danger pour T-SQL !) | bouffon |
Veuillez noter que cet outil de ligne de commande ne produit actuellement PAS de sortie HTML (syntaxe mise en surbrillance). Ce serait une fonctionnalité raisonnablement triviale à ajouter, elle est définitivement prise en charge par la bibliothèque sous-jacente, mais je n'ai vu aucun cas d'utilisation réaliste. Si vous en avez un, merci de me le faire savoir (et/ou fork, ajoutez la ou les options, faites le moi savoir).
Ce formateur « hérite » effectivement de toutes les fonctionnalités de la bibliothèque Poor Man's T-SQL Formatter :
Prise en charge complète de MS SQL Server T-SQL, avec (pour autant que je sache) aucun échec d'analyse ** Y compris la prise en charge complète du code procédural/batch, DDL, DML, etc.
Prise en charge raisonnable d'autres dialectes SQL (régulièrement utilisés pour formater les requêtes PL/SQL, PostgreSql, MySQL, etc.) ** Des constructions spécifiques peuvent ne pas fonctionner ou ne pas être correctement/fidèlement préservées pour ces autres dialectes - veuillez signaler les problèmes lorsque de tels problèmes sont identifiés
Un nombre raisonnable d’options de configuration de formatage, et d’autres sont en route.
Comme indiqué dans la documentation du package de bibliothèque JS (https://github.com/TaoK/poor-mans-t-sql-formatter-npm-package), ce formateur est plutôt lent pour le moment. Sur mon ordinateur portable, le formatage d’une seule requête prend environ une demi-seconde. Cela suggère que pour les charges de travail de formatage en masse, il pourrait être judicieux de proposer une option d'entrée/sortie de fichier générique/récursive.
La prise en charge de l'encodage est également très limitée - comme nous utilisons la prise en charge de l'encodage intégrée du nœud, cela se résume à utf-8 ou utf-16le. Cela vaut peut-être la peine de résoudre ce problème avec la bibliothèque iconv-lite, mais ajouter encore plus de code à charger aurait également ses inconvénients. Quelque chose à penser.
En plus de ces choses, je ne suis au courant d'aucun problème majeur en suspens (par rapport à par exemple la version C# / .Net de ce même formateur de ligne de commande téléchargeable sur http://architectshack.com/PoorMansTSqlFormatter.ashx), donc toute entrée/fonctionnalité les demandes sont les bienvenues !
