One place for hosting & domains

      Configurar

      Cómo leer y configurar variables de entorno y de shell en Linux


      Introducción

      Cuando interactúa con su servidor a través una sesión de shell, hay muchos elementos de información que el shell compila para determinar su comportamiento y acceso a los recursos. Algunas de estas opciones se incluyen en las opciones de configuración, y otras las determina la entrada del usuario.

      Una forma en que el shell realiza un seguimiento de todas estas configuraciones y detalles es en un área que se denomina entorno. El entorno es un área que el shell crea cada vez que inicia una sesión que contiene variables que definen las propiedades del sistema.

      En esta guía, analizaremos cómo interactuar con el entorno y leer o configurar variables de entorno y de shell de forma interactiva y mediante archivos de configuración.

      Cómo funcionan el entorno y las variables de entorno

      Cada vez que se genera una sesión de shell, se lleva a cabo un proceso para recopilar y compilar información que debería estar disponible para el proceso de shell y sus procesos secundarios. Los datos para estas configuraciones se obtienen de diversos archivos y configuraciones en el sistema.

      El entorno proporciona un medio a través del que el proceso de shell puede obtener o establecer configuraciones y, a la vez, transmitirlas a sus procesos secundarios.

      El entorno se implementa como cadenas que representan pares clave-valor. Si se transmiten múltiples valores, estos suelen separarse mediante símbolos de dos puntos (:). Normalmente, cada par tendrá un aspecto similar a este:

      KEY=value1:value2:...
      

      Si el valor contiene un espacio en blanco significativo, se utilizan comillas:

      KEY="value with spaces"
      

      Las claves en estos casos son variables. Pueden ser de dos tipos: variables de entorno o variables de shell.

      Las variables de entorno son variables definidas para el shell actual y heredadas por cualquier shell o proceso secundario. Las variables de entorno se utilizan para transmitir información a procesos que se producen desde el shell.

      Las variables de shell son variables que se encuentran exclusivamente dentro del shell en que se configuraron o definieron. A menudo, se utilizan para realizar un seguimiento de datos efímeros, como el directorio actual de trabajo.

      Por costumbre, estos tipos de variables suelen definirse utilizando letras en mayúsculas. Esto ayuda a los usuarios a distinguir las variables de entorno en otros contextos.

      Impresión de variables de entorno y de shell

      Cada sesión de shell hace un seguimiento de sus propias variables de entorno y de shell. Podemos acceder a ellas de diferentes formas.

      Podemos ver una lista de todas nuestras variables de entorno usando los comandos env o printenv. En su estado predeterminado, deben funcionar exactamente igual:

      Output

      SHELL=/bin/bash TERM=xterm USER=demouser LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca:... MAIL=/var/mail/demouser PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games PWD=/home/demouser LANG=en_US.UTF-8 SHLVL=1 HOME=/home/demouser LOGNAME=demouser LESSOPEN=| /usr/bin/lesspipe %s LESSCLOSE=/usr/bin/lesspipe %s %s _=/usr/bin/printenv

      Esto es bastante típico del resultado de printenv y env. La diferencia entre los dos comandos es visible solamente en su funcionalidad más específica. Por ejemplo, con printenv, puede solicitar los valores de variables individuales:

      Output

      /bin/bash

      Por otro lado, env le permite modificar el entorno en que se ejecutan los programas transmitiendo un conjunto de definiciones de variables a un comando como el siguiente:

      • env VAR1="value" command_to_run command_options

      Dado que, como vimos anteriormente, los procesos secundarios suelen heredar las variables de entorno del proceso principal, esto le da la oportunidad de anular valores o agregar otras variables al proceso secundario.

      Como se puede ver en el resultado de nuestro comando printenv, hay algunas variables de entorno configuradas en los archivos y procesos de nuestro sistema sin nuestra intervención.

      Se muestran las variables de entorno, pero ¿cómo vemos las variables de shell?

      El comando set se puede utilizar para esto. Si escribimos set sin ningún otro parámetro, obtendremos una lista de todas las variables de shell, variables de entorno, variables locales y funciones de shell:

      Output

      BASH=/bin/bash BASHOPTS=checkwinsize:cmdhist:expand_aliases:extglob:extquote:force_fignore:histappend:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=() . . .

      Por lo general, es una lista enorme. Es recomendable canalizarla a un programa de buscapersonas para manejar con mayor facilidad la cantidad de resultados:

      La cantidad de información adicional que recibiremos será un poco abrumadora. Probablemente, no necesitemos saber todas las funciones de bash que se definen, por ejemplo.

      Podemos filtrar el resultado especificando que set debe funcionar en el modo POSIX, lo que no imprimirá las funciones del shell. Podemos ejecutarlo en un subshell para que no cambie nuestro entorno actual:

      Esto enumerará todas las variables de entorno y de shell que están definidas.

      Podemos intentar comparar este resultado con el resultado de los comandos env o printenv para intentar obtener una lista que incluya únicamente variables de shell, pero el resultado no será preciso por las diferentes formas en que estos comandos generan información:

      • comm -23 <(set -o posix; set | sort) <(env | sort)

      Esto probablemente seguirá incluyendo algunas variables de entorno, debido a que el comando set genera valores entre comillas, mientras que los comandos printenv y env no generan los valores de las cadenas entre comillas.

      Aún así, le dará una buena idea de las variables de entorno y de shell que se configuran en su sesión.

      Estas variables se utilizan para toda clase de cosas. Proporcionan una forma alternativa de establecer valores persistentes para la sesión entre procesos, sin realizar cambios en un archivo.

      Variables frecuentes de entorno y de shell

      Algunas variables de entorno y de shell son muy útiles y se utilizan con bastante frecuencia. Aquí hay algunas variables frecuentes de entorno con las que se encontrará:

      • SHELL: Describe el shell que interpretará cualquier comando que ingrese. En la mayoría de los casos, será bash de forma predeterminada, pero se pueden establecer otros valores si prefiere otras opciones.
      • TERM: Especifica el tipo de terminal a emular cuando se ejecuta el shell. Se pueden emular diferentes terminales de hardware para diferentes requisitos de funcionamiento. Sin embargo, generalmente no tendrá que preocuparse por esto.
      • USER: El usuario que inició sesión actualmente.
      • PWD: El directorio actual de trabajo.
      • OLDPWD: El directorio anterior de trabajo. Esto se mantiene en el shell para volver a su directorio anterior ejecutando cd -.
      • LS_COLORS: Define los códigos de color que se utilizan para añadir de forma opcional un resultado de color al comando ls. Esto se utiliza para distinguir diferentes tipos de archivos y proporcionar más información al usuario de forma rápida.
      • MAIL: La ruta al buzón del usuario actual.
      • PATH: Una lista de directorios que el sistema comprobará cuando busque comandos. Cuando un usuario escriba un comando, el sistema comprobará los directorios en este orden para el ejecutable.
      • LANG: Las configuraciones actuales de idioma y localización, incluida la codificación de caracteres.
      • HOME: El directorio principal del usuario actual.
      • _: El comando más reciente ejecutado anteriormente.

      Además de estas variables de entorno, algunas variables de shell que aparecerán a menudo son:

      • BASHOPTS: La lista de opciones que se utilizaron cuando se ejecutó bash. Esto puede ser útil para averiguar si el entorno de shell funcionará de la forma que usted desea.
      • BASH_VERSION: La versión de bash que se está ejecutando, en un formato que los usuarios puedan leer.
      • BASH_VERSINFO: La versión de bash, en un resultado que un equipo pueda leer.
      • COLUMNS: El número de ancho de columnas que se utilizan para generar el resultado en la pantalla.
      • DIRSTACK: La pila de directorios que están disponibles con los comandos pushd y popd.
      • HISTFILESIZE: La cantidad de líneas del historial de comandos que se almancenan en un archivo.
      • HISTSIZE: La cantidad de líneas del historial de comandos que se permiten en la memoria.
      • HOSTNAME: El nombre de host de la computadora en este momento.
      • IFS: El separador de campo interno para separar las entradas en la línea de comandos. De forma predeterminada, es un espacio.
      • PS1: La definición de la entrada del comando principal. Esto se utiliza para definir cómo se ve la entrada de la línea de comandos cuando se inicia una sesión de shell. PS2 se utiliza para declarar las entradas de la línea de comandos secundarias para cuando un comando se extiende a varias líneas.
      • SHELLOPTS: Opciones de shell que se pueden configurar con la opción set.
      • UID: El UID del usuario actual.

      Configuración de variables de entorno y de shell

      Para entender mejor la diferencia entre las variables de entorno y de shell, y para introducir la sintaxis para configurar estas variables, haremos una pequeña demostración.

      Creación de variables de shell

      Empezaremos definiendo una variable de shell en nuestra sesión actual. Esto es fácil de lograr; solo necesitamos especificar un nombre y un valor. Seguiremos la norma de mantener el nombre de la variable en mayúsculas y lo configuraremos en una cadena simple.

      Aquí utilizamos comillas, ya que el valor de nuestra variable contiene un espacio. Además, usamos comillas simples porque el signo de exclamación es un carácter especial en el shell de bash que generalmente se expande al historial de bash si no se escapa o se introduce en comillas simples.

      Ahora, tenemos una variable de shell. Esta variable está disponible en nuestra sesión actual, pero no se transmitirá a los procesos secundarios.

      Podemos ver esto realizando una búsqueda de nuestra nueva variable en el resultado de set:

      Output

      TEST_VAR='Hello World!'

      Podemos verificar que esta no es una variable de entorno intentando lo mismo con printenv:

      No debería aparecer ningún resultado.

      Aprovecharemos esto como una oportunidad para demostrar una forma de acceder al valor de cualquier variable de entorno o de shell.

      Output

      Hello World!

      Como se puede ver, se hace referencia al valor de una variable al precederla con un signo $. El shell interpreta que esto significa que debe sustituir el valor de la variable cuando se encuentre con casos como este.

      Ahora tenemos una variable de shell. No debería transmitirse a ningún proceso secundario. Podemos generar un nuevo shell de bash desde el actual para demostrar:

      Si escribimos bash para generar un shell secundario y, luego, intentamos acceder al contenido de la variable, no se obtendrá ningún resultado. Eso es lo que esperábamos.

      Vuelva a nuestro shell original escribiendo exit:

      Creación de variables de entorno

      Ahora, vamos a convertir nuestra variable de shell en una variable de entorno. Podemos hacer esto exportando la variable. El comando para hacerlo se denomina correctamente:

      Esto convertirá nuestra variable en una variable de entorno. Podemos verificar que el cambio se realizó revisando nuevamente nuestra lista de variables de entorno:

      Output

      TEST_VAR=Hello World!

      Esta vez, aparecerá nuestra variable. Intentemos nuestro experimento de nuevo con nuestro shell secundario:

      Output

      Hello World!

      ¡Genial! Nuestro shell secundario recibió la variable establecida por el shell principal. Antes de salir de este shell secundario, intentemos exportar otra variable. Podemos configurar variables de entorno en un solo paso de esta manera:

      • export NEW_VAR="Testing export"

      Esta es una prueba de que se exportó como variable de entorno:

      Output

      NEW_VAR=Testing export

      Ahora, regresemos a nuestro shell original:

      Veamos si nuestra nueva variable está disponible:

      No se muestra ningún resultado.

      Esto se debe a que las variables de entorno solo se transmiten a procesos secundarios. No hay una forma incorporada de configurar variables de entorno del shell principal. Eso es bueno en la mayoría de casos y evita que los programas afecten al entorno de funcionamiento desde el que fueron invocados.

      La variable NEW_VAR se configuró como una variable de entorno en nuestro shell secundario. Esta variable estaría disponible para sí misma y para cualquiera de sus shells y procesos secundarios. Cuando regresemos a nuestro shell principal, el entorno se eliminará.

      Degradación y anulación de variables

      Todavía tenemos nuestra variable TEST_VAR definida como una variable de entorno. Podemos volver a convertirla en una variable de shell escribiendo:

      Ya no es una variable de entorno:

      Sin embargo, aún es una variable de shell:

      Output

      TEST_VAR='Hello World!'

      Si queremos anular por completo una variable, de shell o de entorno, podemos hacerlo con el comando unset:

      Podemos verificar que ya no está configurada:

      No se genera ningún resultado porque la variable se anuló.

      Configuración de variables de entorno al iniciar sesión

      Ya mencionamos que muchos programas utilizan variables de entorno para decidir los detalles de cómo operar. No queremos tener que configurar variables importantes cada vez que iniciemos una nueva sesión de shell, y ya vimos cuántas variables ya están configuradas al iniciar sesión, entonces ¿cómo creamos y definimos las variables automáticamente?

      En realidad, este es un problema más complejo de lo que parece inicialmente debido a los numerosos archivos de configuración que el shell de bash lee dependiendo de cómo se inicie.

      Diferencia entre las sesiones de shell interactivas, no interactivas, con inicio de sesión y sin inicio de sesión

      El shell de bash lee diferentes archivos de configuración dependiendo de cómo se inicia la sesión.

      Una distinción entre las diferentes sesiones es si el shell se genera como una sesión con inicio de sesión o sin inicio de sesión.

      Un shell con inicio de sesión es una sesión de shell que comienza cuando se autentica al usuario. Si inicia sesión en una sesión de terminal o mediante SSH y realiza una autenticación, la sesión de shell se configurará como un shell con inicio de sesión.

      Si inicia una nueva sesión de shell desde la sesión autenticada, como hicimos invocando al comando bash desde el terminal, se inicia una sesión de shell sin inicio de sesión. No se solicitaron sus detalles de autenticación cuando inició su shell secundario.

      Otra distinción que se puede hacer es si una sesión de shell es interactiva o no interactiva.

      Una sesión de shell interactiva es una sesión de shell que se conecta a un terminal. Una sesión de shell no interactiva es una que no se conecta a una sesión de terminal.

      Cada sesión de shell se clasifica como una sesión con inicio de sesión o sin inicio de sesión y como interactiva o no interactiva.

      Una sesión normal que comienza con SSH suele ser un shell con inicio de sesión interactivo. Normalmente, una secuencia de comandos ejecutada desde la línea de comandos se ejecuta en un shell no interactivo y sin inicio de sesión. Una sesión de terminal puede ser cualquier combinación de estas dos propiedades.

      Si una sesión de shell se clasifica como un shell con inicio de sesión o un shell sin inicio de sesión, tiene repercusiones sobre qué archivos se leen para iniciar la sesión de shell.

      Una sesión iniciada como sesión con inicio de sesión leerá primero los detalles de la configuración del archivo /etc/profile. Luego, buscará el primer archivo de configuración de shell con inicio de sesión en el directorio principal del usuario para obtener detalles de configuración específicos del usuario.

      Lee el primer archivo que puede encontrar con ~/.bash_profile, ~/.bash_login y ~/.profile, y no lee ningún otro archivo.

      Por el contrario, una sesión definida como shell sin inicio de sesión leerá /etc/bash.bashrc y, luego, el archivo ~/.bashrc específico del usuario para crear su entorno.

      Los shells no interactivos leen la variable de entorno llamada BASH_ENV y leen el archivo especificado para definir el nuevo entorno.

      Implementación de variables de entorno

      Como se puede ver, hay diversos archivos que generalmente necesitaríamos revisar para realizar nuestra configuración.

      Eso ofrece gran flexibilidad que puede ser útil en situaciones específicas en que queremos ciertas configuraciones en un shell con inicio de sesión y otras configuraciones en un shell sin inicio de sesión. Sin embargo, la mayoría de las veces preferiremos las mismas configuraciones en ambas situaciones.

      Por suerte, la mayoría de las distribuciones de Linux configura los archivos de configuración con inicio de sesión para obtener los archivos de configuración sin inicio de sesión. Eso significa que puede definir variables de entorno que quiera que sean de ambos tipos de sesión dentro de los archivos de configuración sin inicio de sesión. Luego, se leerán en ambos casos.

      Por lo general, configuraremos variables de entorno específicas de usuario y, normalmente, preferiremos que nuestras configuraciones estén disponibles en shells con inicio de sesión y sin inicio de sesión. Eso significa que el lugar para definir estas variables está en el archivo ~/.bashrc.

      Abra este archivo ahora:

      Lo más probable es que ya contenga bastantes datos. Muchas de las definiciones aquí son para configurar opciones de bash, que no están relacionadas con variables de entorno. Puede configurar variables de entorno de la misma manera en que lo haría en la línea de comandos:

      Cualquier nueva variable de entorno se puede añadir en cualquier lugar del archivo ~/.bashrc, siempre que no se coloque en el medio de otro comando o para crear un bucle. Luego, podemos guardar y cerrar el archivo. La próxima vez que inicie una sesión de shell, su declaración de variable de entorno se leerá y pasará al entorno de shell. Puede forzar su sesión actual a leer el archivo escribiendo lo siguiente:

      Si necesita configurar variables para todo el sistema, es recomendable añadirlas a /etc/profile, /etc/bash.bashrc o /etc/environment.

      Conclusión

      Las variables de entorno y de shell siempre están presentes en las sesiones de shell y pueden ser muy útiles. Son una forma interesante para que un proceso principal establezca los detalles de la configuración para sus procesos secundarios y son una forma de configurar opciones fuera de los archivos.

      Eso tiene muchas ventajas en situaciones específicas. Por ejemplo, algunos mecanismos de implementación utilizan las variables de entorno para configurar la información de autenticación. Eso es útil porque no requiere guardarlos en archivos que terceros puedan ver.

      Hay muchos otros casos más triviales, pero también más frecuentes, en que deberá leer o alterar el entorno de su sistema. Estas herramientas y técnicas le darán una buena base para realizar estos cambios y usarlos correctamente.



      Source link

      Cómo configurar un proyecto Node con Typescript


      Introducción

      Node es un entorno de tiempo de ejecución que hace que sea posible escribir JavaScript en el lado del servidor. Ha logrado una amplia adopción desde su lanzamiento en 2011. Escribir JavaSccript en el servidor puede ser difícil a medida que la base de código crece debido a la naturaleza del lenguaje JavaScript: dinámico y con escritura débil.

      Los desarrolladores que llegan a JavaScript desde otros lenguajes a menudo se quejan sobre su falta de escritura estática fuerte, pero aquí es donde entra TypeScript, para cerrar esta brecha.

      TypeScript es un superconjunto escrito (opcional) de JavaScript que puede ayudar a la hora de crear y gestionar proyectos JavaScript a gran escala. Puede verse como JavaScript con funciones adicionales como escritura estática fuerte, compilación y programación orientada a objetos.

      Nota: TypeScript es técnicamente un superconjunto de JavaScript, lo que significa que todo el código JavaScript es código TypeScript válido.

      Aquí tiene algunos beneficios del uso de TypeScript:

      1. Escritura estática opcional.
      2. Inferencia de escritura.
      3. Capacidad para usar interfaces.

      En este tutorial, configurará un proyecto Node con TypeScript. Creará una aplicación Express usando TypeScript y la convertirá en un código JavaScript limpio y fiable.

      Requisitos previos

      Antes de comenzar con esta guía, necesitará Node.js instalado en su equipo. Puede hacerlo siguiendo la guía Cómo instalar Node.js y crear un entorno de desarrollo local para su sistema operativo.

      Paso 1: Iniciar un proyecto npm

      Para comenzar, cree una nueva carpeta llamada node_project y entre en ese directorio.

      • mkdir node_project
      • cd node_project

      A continuación, inícielo como proyecto npm:

      Tras ejecutar npm init, necesitará suministrar a npm información sobre su proyecto. Si prefiere que npm asuma los valores predeterminados más sensatos, puede añadir el indicador y para omitir las solicitudes de información adicional:

      Ahora que el espacio de su proyecto está configurado, está listo para instalar las dependencias necesarias.

      Paso 2: Instalar las dependencias

      Con un proyecto npm vacío iniciado, el siguiente paso es instalar las dependencias que se necesitan para ejecutar TypeScript.

      Ejecute los siguientes comandos desde el directorio de su proyecto para instalar las dependencias:

      • npm install -D typescript@3.3.3
      • npm install -D tslint@5.12.1

      El indicador -D es el atajo para: --save-dev. Puede obtener más información sobre este indicador en la documentación de npmjs.

      Ahora es el momento de instalar el marco Express:

      • npm install -S express@4.16.4
      • npm install -D @types/express@4.16.1

      El segundo comando instala los tipos de Express para la compatibilidad con TypeScript. Los Tipos de TypeScript son archivos, normalmente con una extensión .d.ts. Los archivos se usan para proporcionar información de tipo sobre una API, en este caso el marco Express.

      Este paquete es necesario porque TypeScript y Express son paquetes independientes. Sin el paquete @typ/express, no hay forma de que TypeScript sepa sobre los tipos de clases Express.

      Paso 3: Configurar TypeScript

      En esta sección, configurará TypeScript y configurará un linting para TypeScript. TypeScript utiliza un archivo llamado tsconfig.json para configurar las opciones del compilador para un proyecto. Cree un archivo tsconfig.json en la raíz del directorio del proyecto y péguelo en el siguiente fragmento de código:

      tsconfig.json

      {
        "compilerOptions": {
          "module": "commonjs",
          "esModuleInterop": true,
          "target": "es6",
          "moduleResolution": "node",
          "sourceMap": true,
          "outDir": "dist"
        },
        "lib": ["es2015"]
      }
      

      Vamos a repasar algunas de las claves del fragmento de código JSON anterior:

      • module: Especifica el método de generación de código del módulo. Node utiliza commonjs.
      • target: Especifica el nivel de lenguaje de salida.
      • moduleResolution: Esto ayuda al compilador a averiguar a qué se refiere una importación. El valor node imita al mecanismo de resolución del módulo de Node.
      • outDir: Esta es la ubicación para los archivos .js tras la transpilación. En este tutorial, lo guardará como dist.

      Una alternativa a crear y popular manualmente el archivo tsconfig.json es ejecutando el siguiente comando:

      Este comando generará un archivo tsconfig.json bien redactado.

      Para obtener más información sobre las opciones de valor clave disponibles, la documentación de TypeScript oficial ofrece explicaciones sobre cada opción.

      Ahora puede configurar el linting de TypeScript para el proyecto. En un terminal que se ejecute en la raíz del directorio de su proyecto, que en este tutorial se estableció como node_project, ejecute el siguiente comando para generar un archivo tslint.json.

      • ./node_modules/.bin/tslint --init

      Abra el archivo tslint.json recién generado y añada la regla no-console como corresponda:

      tslint.json

      {
        "defaultSeverity": "error",
        "extends": ["tslint:recommended"],
        "jsRules": {},
        "rules": {
          "no-console": false
        },
        "rulesDirectory": []
      }
      

      Por defecto, el linter de TypeScript evita el uso de depuración usando declaraciones console, por tanto es necesario indicar explícitamente al linter que revoque la regla no-console predeterminada.

      Paso 4: Actualizar el archivo package.json

      En este momento del tutorial, puede ejecutar funciones en el terminal individualmente o crear un npm script para ejecutarlos.

      En este paso, creará una secuencia de comandos start que compilará y transpilará el código de TypeScript, y luego ejecutará la aplicación .js resultante.

      Abra el archivo package.json y actualícelo:

      package.json

      {
        "name": "node-with-ts",
        "version": "1.0.0",
        "description": "",
        "main": "dist/app.js",
        "scripts": {
          "start": "tsc && node dist/app.js",
          "test": "echo "Error: no test specified" && exit 1"
        },
        "author": "",
        "license": "ISC",
        "devDependencies": {
          "@types/express": "^4.16.1",
          "tslint": "^5.12.1",
          "typescript": "^3.3.3"
        },
        "dependencies": {
          "express": "^4.16.4"
        }
      }
      

      En el fragmento de código anterior, actualizó la ruta main y añadió el comando start a la sección scripts. Cuando se observa el comando start, verá que primero se ejecuta el comando tsc y luego el comando node. Esto compilará y ejecutará el resultado generado con node.

      El comando tsc indica a TypeScript que compile la aplicación y coloque el resultado .jso generado en el directorio outDir especificado como se establece en el archivo tsconfig.json.

      Paso 5: Crear y ejecutar un servidor Express básico

      Ahora que TypeScript y su linter están configurados, es el momento de crear un servidor Node Express.

      Primero cree una carpeta src en la raíz del directorio de su proyecto:

      A continuación cree un archivo llamado app.ts dentro:

      En este momento, la estructura de la carpeta debería tener este aspecto:

      ├── node_modules/
      ├── src/
        ├── app.ts
      ├── package-lock.json
      ├── package.json
      ├── tsconfig.json
      ├── tslint.json
      

      Abra el archivo app.ts con el editor de texto que prefiera y pegue el siguiente fragmento de código:

      src/app.ts

      import express from 'express';
      
      const app = express();
      const port = 3000;
      app.get('/', (req, res) => {
        res.send('The sedulous hyena ate the antelope!');
      });
      app.listen(port, err => {
        if (err) {
          return console.error(err);
        }
        return console.log(`server is listening on ${port}`);
      });
      

      El código anterior crea Node Server que escucha las solicitudes sobre el puerto 3000. Ejecute la aplicación usando el siguiente comando:

      Si se ejecuta correctamente se registrará un mensaje en el terminal:

      Output

      • server is listening on 3000

      Ahora, puede visitar http://localhost:3000 en su navegador y debería ver el mensaje:

      Output

      • The sedulous hyena ate the antelope!

      Ventana del navegador con el mensaje: The sedulous hyena ate the antelope!

      Abra el archivo dist/app.js y encontrará la versión transpilada del código TypeScript:

      dist/app.js

      "use strict";
      
      var __importDefault = (this && this.__importDefault) || function (mod) {
          return (mod && mod.__esModule) ? mod : { "default": mod };
      };
      Object.defineProperty(exports, "__esModule", { value: true });
      const express_1 = __importDefault(require("express"));
      const app = express_1.default();
      const port = 3000;
      app.get('/', (req, res) => {
          res.send('The sedulous hyena ate the antelope!');
      });
      app.listen(port, err => {
          if (err) {
              return console.error(err);
          }
          return console.log(`server is listening on ${port}`);
      });
      
      //# sourceMappingURL=app.js.map
      

      En este momento ha configurado correctamente su proyecto Node para usar TypeScript.

      Conclusión

      En este tutorial, aprendió por qué TypeScript es útil para escribir un código JavaScript fiable. También aprendió algunos de los beneficios de trabajar con TypeScript.

      Finalmente, ha configurado un proyecto Node usando el marco Express, pero compiló y ejecutó el proyecto usando TypeScript.



      Source link

      Como configurar um projeto de nó com o Typescript


      Introdução

      O Node é um ambiente de de execução que permite escrever JavaScript do lado do servidor. Desde seu lançamento em 2011, ele vem sendo adotado amplamente. Escrever JavaScript do lado do servidor pode ser uma tarefa desafiadora à medida que a base de código cresce. Isso ocorre devido à natureza da linguagem JavaScript; é dinâmica e fracamente tipada.

      Deselvolvedores que vêm para o JavaScript de outra linguagem geralmente reclamam da falta de uma tipagem estática forte e é por isso que o TypeScript existe – para preencher essa lacuna.

      O TypeScript é um superconjunto tipado (opcional) de JavaScript que pode auxiliar na construção e gerenciamento de projetos em JavaScript em larga escala. Ele pode ser considerado um JavaScript com funcionalidades adicionais, tais como uma tipagem estática forte, compilação e programação orientada a objetos.

      Nota: o TypeScript é tecnicamente um superconjunto de JavaScript, o que significa que todo o código de JavaScript é também um código de TypeScript válido.

      Aqui estão alguns benefícios de usar o TypeScript:

      1. Tipagem estática opcional.
      2. Inferência de tipo.
      3. Capacidade de usar interfaces.

      Neste tutorial, você irá configurar um projeto do Node com o TypeScript. Você irá construir um aplicativo Express usando o TypeScript e transcompilá-lo em um código JavaScript organizado e confiável.

      Pré-requisitos

      Antes de iniciar este guia, é necessário possuir o Node.js instalado em sua máquina. Você pode fazer isso seguindo o guia Como instalar o Node.js e criar um ambiente de desenvolvimento local para seu sistema operacional.

      Passo 1 — Inicializando um projeto npm

      Para começar, crie uma nova pasta chamada node_project e vá até esse diretório.

      • mkdir node_project
      • cd node_project

      Em seguida, inicialize-o como um projeto npm:

      Depois de executar o npm init, será necessário fornecer informações sobre o seu projeto ao npm. Caso prefira deixar que o npm assuma padrões sensatos, adicione o sinalizador y para ignorar os prompts para obter informações adicionais:

      Agora que seu espaço de projeto está configurado, podemos seguir para a instalação das dependências necessárias.

      Passo 2 — Instalando as dependências

      Com um projeto básico do npm inicializado, o próximo passo é instalar as dependências que são necessárias para executar o TypeScript.

      Execute os seguintes comandos a partir do diretório do seu projeto para instalar as dependências:

      • npm install -D typescript@3.3.3
      • npm install -D tslint@5.12.1

      O sinalizador -D é o atalho para: --save-dev. Aprenda mais sobre esse sinalizador na documentação do npmjs.

      Agora, é hora de instalar o framework Express:

      • npm install -S express@4.16.4
      • npm install -D @types/express@4.16.1

      O segundo comando instala os tipos do Express para o suporte do TypeScript. Os tipos no TypeScript são arquivos, normalmente com uma extensão .d.ts. Os arquivos são usados para fornecer informações de tipo sobre uma API, neste caso, o framework Express.

      Este pacote é necessário porque o TypeScript e o Express são pacotes independentes. Sem o pacote @types/express, o TypeScript não é capaz de saber sobre os tipos das classes do Express.

      Passo 3 — Configurando o TypeScript

      Nesta seção, você irá configurar o TypeScript e configurar uma função de linting para ele. O TypeScript usa um arquivo chamado tsconfig.json para configurar as opções do compilador para um projeto. Crie um arquivo tsconfig.json na raiz do diretório do projeto e adicione o seguinte trecho de código:

      tsconfig.json

      {
        "compilerOptions": {
          "module": "commonjs",
          "esModuleInterop": true,
          "target": "es6",
          "moduleResolution": "node",
          "sourceMap": true,
          "outDir": "dist"
        },
        "lib": ["es2015"]
      }
      

      Vamos rever algumas das chaves presentes no código JSON acima:

      • module: define o método de geração de código do módulo. O Node usa o commonjs.
      • target: especifica o nível de linguagem de saída.
      • moduleResolution: isso ajuda o compilador a descobrir a que uma importação se refere. O valor node imita o mecanismo de resolução de módulo do Node.
      • outDir: essa é a localização onde serão gerados os arquivos .js após a transcompilação. Neste tutorial, você irá salvá-lo como dist.

      Ao invés de criar e preencher manualmente o arquivo tsconfig.json, uma alternativa é executar o comando a seguir:

      Esse comando irá gerar um arquivo tsconfig.json comentado de maneira satisfatória.

      Para aprender mais sobre as opções de valor chave disponíveis, a documentação oficial do TypeScript oferece explicações de todas as opções.

      Agora, configure o linting do TypeScript para o projeto. Em um terminal em execução na raiz do diretório do seu projeto, que este tutorial estabeleceu como sendo node_project, execute o comando a seguir para gerar um arquivo tslint.json:

      • ./node_modules/.bin/tslint --init

      Abra o arquivo tslint.json recém-gerado e adicione a regra no-console adequadamente:

      tslint.json

      {
        "defaultSeverity": "error",
        "extends": ["tslint:recommended"],
        "jsRules": {},
        "rules": {
          "no-console": false
        },
        "rulesDirectory": []
      }
      

      Por padrão, o linter do TypeScript impede a depuração usando declarações de console. Dessa forma, é necessário dizer explicitamente ao linter para revogar a regra no-console padrão.

      Passo 4 — Atualizando o arquivo package.json

      Neste ponto do tutorial, é possível executar funções no terminal individualmente, ou criar um script npm para executá-las.

      Neste passo, você criará um script start que irá compilar e transcompilar o código TypeScript e então executar o aplicativo .js resultante.

      Abra o arquivo package.json e atualize-o adequadamente:

      package.json

      {
        "name": "node-with-ts",
        "version": "1.0.0",
        "description": "",
        "main": "dist/app.js",
        "scripts": {
          "start": "tsc && node dist/app.js",
          "test": "echo "Error: no test specified" && exit 1"
        },
        "author": "",
        "license": "ISC",
        "devDependencies": {
          "@types/express": "^4.16.1",
          "tslint": "^5.12.1",
          "typescript": "^3.3.3"
        },
        "dependencies": {
          "express": "^4.16.4"
        }
      }
      

      No código acima, você atualizou o caminho main e adicionou o comando start à seção de scripts. Se observar o comando start, você verá que primeiro o comando tsc é executado e, em seguida, o comando node. Isso irá compilar e então executar a saída gerada com o node.

      O comando tsc diz ao TypeScript para compilar o aplicativo e colocar a saída .js gerada no diretório outDir especificado, da forma como está definido no arquivo tsconfig.json.

      Passo 5 — Criando e executando um servidor básico do Express

      Agora que o TypeScript e seu linter estão configurados, é hora de construir um servidor do Node Express.

      Primeiro, crie uma pasta src na raiz do diretório do seu projeto:

      Em seguida, crie um arquivo chamado app.ts dentro dela:

      Neste ponto, a estrutura da pasta deve se parecer com esta:

      ├── node_modules/
      ├── src/
        ├── app.ts
      ├── package-lock.json
      ├── package.json
      ├── tsconfig.json
      ├── tslint.json
      

      Abra o arquivo app.ts com um editor de texto da sua escolha e adicione o trecho de código a seguir:

      src/app.ts

      import express from 'express';
      
      const app = express();
      const port = 3000;
      app.get('/', (req, res) => {
        res.send('The sedulous hyena ate the antelope!');
      });
      app.listen(port, err => {
        if (err) {
          return console.error(err);
        }
        return console.log(`server is listening on ${port}`);
      });
      

      O código acima cria um servidor Node que escuta na porta 3000 para solicitações. Execute o aplicativo usando o comando a seguir:

      Se ele for executado com sucesso, uma mensagem será registrada no terminal:

      Output

      • server is listening on 3000

      Agora, visite http://localhost:3000 em seu navegador e você verá esta mensagem:

      Output

      • The sedulous hyena ate the antelope!

      Janela do navegador com a mensagem: The sedulous hyena ate the antelope!

      Abra o arquivo dist/app.js e você encontrará a versão transcompilada do código do TypeScript:

      dist/app.js

      "use strict";
      
      var __importDefault = (this && this.__importDefault) || function (mod) {
          return (mod && mod.__esModule) ? mod : { "default": mod };
      };
      Object.defineProperty(exports, "__esModule", { value: true });
      const express_1 = __importDefault(require("express"));
      const app = express_1.default();
      const port = 3000;
      app.get('/', (req, res) => {
          res.send('The sedulous hyena ate the antelope!');
      });
      app.listen(port, err => {
          if (err) {
              return console.error(err);
          }
          return console.log(`server is listening on ${port}`);
      });
      
      //# sourceMappingURL=app.js.map
      

      Neste ponto, você terminou de configurar com sucesso seu projeto Node para usar o TypeScript.

      Conclusão

      Neste tutorial, você aprendeu sobre a razão pela qual o TypeScript é útil para escrever códigos em JavaScript confiáveis. Você também aprendeu sobre alguns dos benefícios de trabalhar com o TypeScript.

      Por fim, você configurou um projeto Node usando o framework Express, mas compilou e executou o projeto usando o TypeScript.



      Source link