Differences

This shows you the differences between two versions of the page.

--- apuntes:configuracion [2026/09/28 18:18] – Santiago Faci
+++ apuntes:configuracion [2026/10/28 00:52] (current) – [Mantener estilos y convenciones entre diferentes IDEs: EditorConfig] Santiago Faci
@@ Line 5: / Line 5: @@
 <caption>Buenas prácticas en la configuración de proyectos</caption>
 </figure>
+===== Convenciones de código / Guias de estilo =====
+No existe ninguna guia de estilo oficial para desarrollar con lenguaje Javascript. Diferentes organizaciones o compañias elaboran las suyas propias para uso interno o bien para extender un buen estilo entre desarrolladores.
+Lo más importantes, al margen de escoger una u otra, es ser consistente con las convenciones de código o estilo que se decida seguir.
+Os dejo aqui un par de guias de estilo a modo de ejemplo:
+  * [[https://www.mediawiki.org/wiki/Manual:Coding_conventions#JavaScript|MediaWiki Javascript Style Guide]]
+  * [[https://google.github.io/styleguide/jsguide.html|Google Javascript Style Guide]]
 ===== Contenido generado =====
@@ Line 30: / Line 41: @@
 indent_style = space
 indent_size = 4
+insert_final_newline = true
+trim_trailing_whitespace = true
 </file>
@@ Line 80: / Line 93: @@
 Para saber qué cambios ha habido en una release/version concreta, tendremos que consultar lo que se conoce como //Changelog//. Por ejemplo, en https://nodejs.org/en/download/archive/v24.21.0 se pueden consultar el de Node v24 junto con otros detalles sobre esa release.
+===== Cómo mantengo mi proyecto actualizado? =====
+Otra parte importante, relacionada con el ciclo de vida del proyecto, es el cómo mantener el proyecto actualizado. Cualquier aplicación que hayamos desarrollado seguro que usará un número determinado de librerias (dependencias). Cada una de ellas es también a su vez un proyecto con su propio ciclo de vida:
+  * Aparecerán nuevas releases de esas dependencias con nuevas funcionalidades (normalmente proporcionando //backward compatibility// (compatibilidad hacia atrás)
+  * Algunas de esas releases simplemente corrigen fallos de seguridad (que pueden ser muy críticos)
+  * Otras releases pueden contener lo que se conoce como //breaking changes//, lo que significa que algo podría dejar de funcionar o funcionar de forma inesperada si se actualiza a una versión concreta de esa dependencia (pero probablemente el ciclo de vida de esas librerias me acabará obligando a hacerlo en algún momento)
+  * Una versión concreta de una dependencias, digamos 2.x.x, puede dejar de recibir cambios por llegar al final de su ciclo de vida. Podemos vernos obligados a pasar a la nueva versión, 3.x.x, con los cambios que ello podría suponer
+En el caso de proyectos Node.js, estos son algunos comandos que nos serán de utilidad a la hora de actualizar las dependencias de mi proyecto (algo que tendremos que hacer periódicamente):
+  * ''npm audit'': Revisa todas las librerías utilizadas por el proyecto en busca de las vulnerabilidades asociadas a la versión especifica que se está usando
+  * ''npm audit --fix'': Corrige las librerías que contengan vulnerabilidades que no contengan //breaking changes//, actualizando éstas a una nueva release. Actualiza el fichero ''package-lock.json'' y la carpeta ''node_modules''. Y actualizará el fichero ''package.json'' solamente cuando la librería que contenía la vulnerabilidad fuera una de las definidas en dicho fichero, y siempre según las reglas definidas en él.
+  * ''npm outdated'': Muestra qué librerías están ya obsoletas comparándolas con las que está disponibles en el registro público de npm. No realiza ningún cambio ni actualización.
+  * ''npm update'': Actualiza las dependencias del proyecto conforme a lo definido en el fichero ''package.json''. Modifica el fichero ''package-lock.json'' y la carpeta ''node_modules'' pero no toca el fichero ''package.json''.
+  * ''npm update --save'': Actualiza las dependencias del proyecto conforme al comando anterior y actualiza también el fichero ''package.json'' con la versión mínimas de aquellas librerías que hayan sido actualizadas.
+A la hora de actualizar las dependencias será muy importante gestionar correctamente el [[https://docs.npmjs.com/about-semantic-versioning|versionado semántico]] de las librerias en el fichero ''package.json''.
+La información de todas las dependencias públicas disponibles para el framework Node.js se encuentran disponibles en el [[https://www.npmjs.com/|npm registry]], que contiene la información que el comando ''npm'' utiliza para realizar todas sus funciones.
 ===== Uso de linters =====
@@ Line 214: / Line 247: @@
 ===== Ficheros de configuración =====
+Los ficheros de configuración se utilizan como vía para modificar el comportamiento de una aplicación sin tener que redesplegarla. Un cambio en el valor de una propiedad del fichero de configuración bastará para que la aplicación haga algo de forma diferente (siempre y cuando dicho comportamiento haya sido implementado en base a la propiedad correspondiente).
+Normalmente se utiliza un fichero con sintaxis ''yaml'' para almacenar la configuración:
 <code yaml config.local.yaml>
@@ Line 226: / Line 263: @@
   port: 8080
 </code>
+Cómo cargar el fichero de configuración (la variable ''config'' acaba almacenando el contenido del fichero)
 <file javascript config/configuration.js>
@@ Line 323: / Line 362: @@
 ===== Mock API =====
-<file json db.json>
+<file javascript db.json>
 {
   "$schema": "./node_modules/json-server/schema.json",
@@ Line 348: / Line 387: @@
 santi@zenbook:$ npx json-server db.json
 </code>
+----
+====== Ejercicios ======
+  - Configura un proyecto nodejs para que haga uso de ''eslint'' y se ejecute un análisis estático del código con 'npm run lint'. ''npm run lint:fix'' deberá lanzar el análisis y además corregir los fallos que sea posible.
 ----