Indicadores de línea de comando por el binario de Node

En este artículo, aprenderemos sobre los indicadores de línea de comando que ofrece el binario Node . La plataforma Node.js está representada casi en su totalidad por el ejecutable binario del Node. Para ejecutar un programa JavaScript usamos: node app.js , donde app.js es el programa que deseamos ejecutar. Sin embargo, antes de que podamos comenzar a ejecutar programas, debemos aprender algunos indicadores básicos de la línea de comandos que ofrece el binario Node y cómo usarlos.

Opciones de comando de impresión: para ver las banderas de la línea de comandos para cualquier versión del Node, podemos usar la bandera –help . Escribe el siguiente código en la terminal:

node --help

 

Más allá de las banderas de la línea de comandos de Node, hay banderas adicionales para modificar el motor de tiempo de ejecución de JavaScript: V8. Para ver, estas banderas ejecutan node –v8-options . Escribe el siguiente código en la terminal:

node --v8-options

 

Todo esto se trataba de la línea de comandos, ahora necesitamos saber cómo usarla para ahorrarnos la molestia mientras se ejecuta el programa. Como sabrá, el requisito más básico para que un programa se ejecute es que no debe haber ningún error de sintaxis. Algunos IDE populares como VS Code vienen con herramientas como Intellisense que informa a los usuarios en caso de errores de sintaxis, pero ¿qué pasa si no desea usar las extensiones y realmente usa la línea de comando para saber si hay algún error de sintaxis? El binario del Node también ayuda en esto.

Comprobación de la sintaxis: es posible analizar la aplicación JavaScript sin ejecutarla realmente, solo para comprobar la sintaxis.

Para comprobar la sintaxis podemos usar:

node --check app.js
node -c app.js

Nota: Se puede usar cualquiera de las banderas de la lista anterior. En el análisis exitoso, sucede una de las dos cosas:

• No hay ningún error de sintaxis y no se genera ningún resultado.
• Hay un error y se muestra un mensaje de error en la ventana del terminal.\

Ejemplo 1: Este es el Caso 1 donde no hay ningún error de sintaxis:

const func = () => {
    console.log("This block of code is "
      + "the example of good/correct syntax");
}

Paso para verificar la sintaxis: escriba el siguiente código en la terminal para verificar la sintaxis:

node --check app.js

Producción:

 

Ejemplo 2: Este es el Caso 2 donde hay un error de sintaxis.

const func: () => {
    console.log("This block of code is an example of incorrect syntax.");
}

Paso para verificar la sintaxis: escriba el siguiente código en la terminal para verificar la sintaxis:

node --check app.js

Producción:

 

De esta forma, podemos comprobar si nuestro código tiene o no algún error de sintaxis.

Evaluación dinámica: el Node puede evaluar directamente el código del shell, lo que se vuelve muy útil para verificar rápidamente un fragmento de código. Hay dos banderas que pueden evaluar el código. Son los siguientes:

•  -p o –print: Evalúa la expresión e imprime el resultado.
•  – e o –eval: evalúa la expresión pero no imprime el resultado.

Aquí hay algunos ejemplos de cómo funcionan los indicadores –print y – -eval :

node -p "2+2"
node -e "2+2"

 

Como puede ver, el indicador – p evalúa la expresión 2+2  e imprime 4 como salida.

Considere otro ejemplo que evalúa la función console.log en la línea de comando:

node -e "console.log(2)"

 

El indicador –eval o -e no genera ningún resultado, pero aquí, como console.log imprime 2 , el resultado se genera explícitamente.

De manera similar, cuando se evalúa console.log  usando el indicador –print , esto es lo que obtenemos como resultado:

node -p "console.log(2)"

 

2 se genera como salida porque se imprime explícitamente usando la función console.log , también se imprime undefined en el terminal porque console.log en sí mismo devuelve undefined.

Otro ejemplo es donde podemos usar el indicador -p o – -print para imprimir todos los archivos con la extensión .js en el directorio de trabajo actual.

Para el siguiente ejemplo, estos son los archivos que tenemos en el directorio actual:

 

Podemos usar el indicador –print de la siguiente manera:

node -p "fs.readdirSync('.').filter(cf=>/.js$/.text(cf))"

 

Carga previa de módulos CommonJs: el indicador de línea de comando -r o –require se puede usar para precargar un módulo CommonJS antes de que se cargue cualquier otra cosa.

Supongamos que hay dos archivos preload.j s y app.js y su contenido es el siguiente:

 

Ahora, para precargar un archivo sobre otro, podemos usar el indicador –require de la siguiente manera:

node --require ./preload.js app.js

 

La precarga de módulos es útil cuando se utilizan módulos de consumo que instrumentan o configuran el proceso de alguna manera.

NOTA: Hay dos sistemas de módulos que utiliza Node, CommonJS y ESM, pero es importante tener en cuenta aquí que el indicador –require solo puede precargar un módulo CommonJS, no un módulo ESM. Los módulos ESM tienen una bandera vagamente relacionada, llamada –loader, una bandera actualmente experimental que no debe confundirse con la bandera –require preloader. Para obtener más información sobre los módulos CommonJS y ESM, consulte la documentación del Node aquí .

Límite de seguimiento de pila: los seguimientos de pila se generan para cualquier error que se produzca, por lo que suelen ser el primer punto de llamada al depurar un escenario de error. De forma predeterminada, un seguimiento de pila contendrá los últimos diez marcos de pila (sitios de llamada de función) en el punto donde se produjo el seguimiento. Esto a menudo está bien porque la parte de la pila que le interesa a menudo son los últimos 3 o 4 marcos de llamada. Sin embargo, hay escenarios en los que tiene sentido ver más marcos de llamadas en un seguimiento de la pila, como verificar que el flujo de la aplicación a través de varias funciones sea el esperado.

El límite de seguimiento de la pila se puede modificar con el indicador –stack-trace-limit . Esta marca es parte del motor de tiempo de ejecución de JavaScript, V8, y se puede encontrar en la salida de la marca – -v8-options .

Considere un archivo llamado will-throw.js, con el siguiente contenido:

function f(n = 99) {
    if (n == 85)
        throw Error();
    f(n - 1)
}
f()

Cuando ejecutamos el siguiente comando en la línea de comandos:

node --stack-trace-limit=10 will-throw.js 

Solo habrá diez marcos de pila en la salida de error porque el límite se establece explícitamente en 10.

¿Qué pasa si establecemos el límite para decir 1000 , algo como esto:

node --stack-trace-limit=1000 will-throw.js

En este caso, podemos mostrar la salida en 1000 marcos de pila.

Vemos que establecer el límite de seguimiento de la pila en un número mayor que el número de marcos de llamada en la pila garantiza que se generará toda la pila (en nuestro caso, mayor que 85).

Pero espere, ¿es realmente factible cambiar el límite predeterminado de los marcos de pila?

La respuesta es NO porque en los escenarios de producción, la sobrecarga involucrada con la retención de pilas largas no solo causará una sobrecarga sino que también consumirá una gran cantidad de espacio de memoria, lo que en última instancia degradará el rendimiento de su aplicación.