poor mans t sql formatter npm cli
1.0.0
Un formateador SQL de línea de comandos que se ejecuta en prácticamente cualquier entorno (siempre que node.js esté instalado).
Se basa en el paquete NPM Poor Man's T-SQL Formatter (poor-mans-t-sql-formatter), que a su vez se basa en la biblioteca C# del mismo nombre (https://github.com/TaoK/PoorMansTSqlFormatter ).
Este formateador debería ser equivalente en funcionalidad al formateador de línea de comandos de C# que existe desde hace algunos años (descargable en http://architectshack.com/PoorMansTSqlFormatter.ashx), con dos diferencias principales:
Es muy fácil de instalar, especialmente en entornos Unixey, siempre que Node.js esté disponible.
Es bastante más lento que el formateador basado en .Net.
(suponiendo que node.js esté instalado)
npm install --global poor-mans-t-sql-formatter-cli
entrada canalizada/stdin y salida stdout:
echo "select a from b join c on b.id = c.id where abc = 123 and def = N'whatêver' " | sqlformat
entrada y salida de archivos:
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
Este formateador de línea de comandos saldrá con un código de salida distinto de 0 si el análisis de SQL "tiene problemas", por ejemplo, si encuentra una declaración "IF" sin terminar, lo que sugiere que algo sobre el SQL no se entendió/analizó correctamente, y por tanto "salir mal". Existe una opción para desactivar este comportamiento si se sabe que el SQL es dudoso o que la confusión en el análisis es inocua.
Si se cancela el análisis, cualquier "archivo de salida" especificado quedará intacto.
Opciones específicas de la utilidad de línea de comandos:
| Opción | Descripción | Tipo | Por defecto |
|---|---|---|---|
| --archivo de entrada | Leer la entrada que se va a formatear desde un archivo en lugar de la entrada estándar (entrada escrita o canalizada) | cadena | |
| --archivodesalida | Escriba la salida formateada en un archivo, como la redirección de shell de stdout, excepto que, en caso de error, deja el archivo intacto. | cadena | |
| --ignoreErrores | Devuelve un código de salida 0 (éxito) incluso si el análisis falla (por lo que la salida formateada es sospechosa) | booleano | |
| --inputCodificación | Utilice una codificación de caracteres específica admitida por el nodo para la entrada, básicamente utf-16le o utf-8 | cadena | utf-8 |
| --codificación de salida | Utilice una codificación de caracteres específica admitida por el nodo para la salida, básicamente utf-16le o utf-8 | cadena | utf-8 |
| --forceOutputBOM | Agregue una marca de orden de bytes (BOM) al inicio de la salida | booleano |
Opciones de formateador estándar:
(tenga en cuenta que las opciones booleanas que normalmente son "verdaderas" en la biblioteca se han invertido con un prefijo "no", siguiendo las convenciones de parámetros de línea de comandos de Unixey)
| Opción | Descripción | Tipo | Por defecto |
|---|---|---|---|
| --sangrar | La unidad de sangría: normalmente una tabulación (t) o varios espacios. | cadena | t |
| --maxLineWidth | Solicite que el formateador ajuste las líneas largas para evitar exceder esta longitud de línea | entero | 999 |
| --espaciosPorTab | Esto se usa para medir la longitud de la línea y solo se aplica si usa pestañas. | entero | 4 |
| --statementBreaks | ¿Cuántos saltos de línea se deben agregar al iniciar una nueva declaración? | entero | 2 |
| --clauseBreaks | ¿Cuántos saltos de línea se deben agregar al iniciar una nueva cláusula dentro de una declaración? | entero | 1 |
| --no-expandCommaLists | ¿Deberían dividirse las listas delimitadas por comas (columnas, grupos por argumentos, etc.) en nuevas líneas? | booleano | |
| --comas sin seguimiento | Al comenzar una nueva línea debido a una coma, ¿la coma debería estar al final de la línea (frente al comienzo de la siguiente)? | booleano | |
| --spaceAfterExpandedComma | ¿Se debe agregar un espacio después de la coma? (normalmente no si están "a la zaga") | booleano | |
| --no-expandBooleanExpressions | ¿Deberían los operadores booleanos (Y, O) provocar un salto de línea? | booleano | |
| --no-expandCaseStatements | ¿Las expresiones CASE deberían tener sus expresiones CUANDO y ENTONCES divididas en nuevas líneas? | booleano | |
| --no-expandirEntreCondiciones | ¿Las expresiones ENTRE deberían tener el argumento máximo dividido en una nueva línea? | booleano | |
| --expandirEnListas | ¿Las listas IN() deberían tener cada argumento en una nueva línea? | booleano | |
| --breakJoinOnSections | ¿Debería dividirse la sección ON de una cláusula JOIN en su propia línea? | booleano | |
| --palabras clave sin mayúsculas | ¿Las palabras clave T-SQL (como SELECT, FROM) deberían escribirse automáticamente en mayúsculas? | booleano | |
| --keywordEstandarización | ¿Deberían reemplazarse las palabras clave T-SQL menos comunes por sus contrapartes estándar? (NOTA: ¡solo es seguro para T-SQL!) | booleano |
Ofuscar las opciones del formateador (comando "min"):
| Opción | Descripción | Tipo | Por defecto |
|---|---|---|---|
| --randomizeKeywordCase | ¿Deberían ser aleatorias las palabras clave para minimizar la legibilidad? | booleano | |
| --randomizeLineLengths | ¿Debería ajustarse el SQL a intervalos arbitrarios para minimizar la legibilidad? | booleano | |
| --no-preserveComentarios | ¿Deben conservarse los comentarios en el código (en lugar de eliminarse)? | booleano | |
| --enableSustitución de palabras clave | ¿Las palabras clave con sinónimos deberían utilizar formas menos comunes? (NOTA: ¡solo es seguro para T-SQL!) | booleano |
Tenga en cuenta que esta herramienta de línea de comandos NO produce actualmente resultados HTML (resaltados con sintaxis). Esta sería una característica razonablemente trivial de agregar; definitivamente es compatible con la biblioteca subyacente, pero no he visto ningún caso de uso realista. Si tiene uno, hágamelo saber (y/o bifurque, agregue las opciones, hágamelo saber).
Este formateador "hereda" efectivamente toda la funcionalidad de la biblioteca de formateador T-SQL de Poor Man:
Soporte completo para MS SQL Server T-SQL, sin (hasta donde yo sé) fallas de análisis ** Incluye soporte completo de código de procedimiento/por lotes, DDL, DML, etc.
Soporte razonable para otros dialectos SQL (usados regularmente para formatear consultas PL/SQL, PostgreSql, MySQL, etc.) ** Es posible que construcciones específicas no funcionen o no se conserven correcta/fielmente para esos otros dialectos; presente los problemas cuando se identifiquen dichas inquietudes.
Un número razonable de opciones de configuración de formato, y hay más en camino.
Como se indica en el documento del paquete de la biblioteca JS (https://github.com/TaoK/poor-mans-t-sql-formatter-npm-package), este formateador es bastante lento en este momento. En mi computadora portátil, formatear una sola consulta lleva aproximadamente medio segundo. Eso sugiere que para cargas de trabajo de formato masivo, podría tener sentido ofrecer una opción de entrada/salida de archivos recursivo/comodín.
El soporte de codificación también es muy limitado: como utilizamos el soporte de codificación integrado del nodo, todo se reduce a utf-8 o utf-16le. Podría valer la pena solucionar este problema con la biblioteca iconv-lite, pero agregar aún más código para cargar también tendría sus desventajas. Algo en qué pensar.
Además de estas cosas, no conozco ninguna preocupación importante pendiente (en comparación con, por ejemplo, la versión C#/.Net de este mismo formateador de línea de comandos que se puede descargar en http://architectshack.com/PoorMansTSqlFormatter.ashx), por lo que cualquier entrada/función ¡Las solicitudes son bienvenidas!
