Examen nivel 1 — Node.js

Examen — preguntas inéditas

12 preguntas para validar JavaScript y bases de Node: JS moderno, asincronía, módulos CommonJS/ESM y gestión de proyecto npm.
Responde a todo y pulsa Corregir: aparecerán tu puntuación y las explicaciones.

1.1 · Recuerdo

1. ¿Qué reflejo adoptar para declarar variables en JavaScript moderno?

const por defecto, let si hay reasignación, nunca var var en todas partes, como antes let en todas partes, nunca const No declarar ya variables en absoluto

const por defecto (referencia estable, ámbito de bloque), let si el valor evoluciona, var desterrado.

1.1 · Aplicación

2. Salim quiere los nombres de los usuarios activos desde un array users. ¿Escritura moderna?

users.filter(u => u.actif).map(u => u.nom) Un bucle for con índice y push manuales Copiar cada nombre a mano en un nuevo array Ordenar el array y tomar los primeros elementos

filter conserva (los activos), map transforma (sus nombres): la intención se lee de un vistazo.

1.1 · Arbitraje

3. Salim relee const config = { port: 3000 } y luego config.port = 4000. ¿Arbitraje?

Está prohibido: const hace el objeto inmutable, el código fallará Hay que pasar la variable a var para modificarla Es válido: const impide la reasignación, no la modificación del contenido Hay que recrear todo el objeto con cada cambio de campo

const protege la «caja» (la referencia), no su contenido: modificar un campo sigue siendo posible.

1.2 · Recuerdo

4. ¿Qué hace await en una función async?

Transforma la operación en código síncrono clásico Ignora los errores de la operación Espera el resultado sin bloquear, el código se lee en orden Bloquea todo el programa como un sleep

await suspende la función mientras espera la promesa sin bloquear el bucle de eventos.

1.2 · Aplicación

5. El console.log de Salim muestra undefined justo después de una llamada asíncrona. ¿Causa?

console.log no funciona con los archivos El archivo leído está forzosamente vacío Node.js está roto, hay que reinstalarlo Lee el resultado demasiado pronto: la operación aún no ha terminado

Lanzar no es obtener: el resultado llega más tarde (callback, .then() o await).

1.2 · Aplicación

6. Salim encadena tres operaciones dependientes (archivo → base → API). ¿Escritura recomendada?

Tres await ordenados en una función async con try/catch Tres lecturas síncronas bloqueantes en serie Un setTimeout arbitrario entre cada operación Tres callbacks anidados en pirámide

async/await: el código se lee en orden, sin bloquear, errores gestionados en el mismo lugar.

1.3 · Aplicación

7. Salim importa su módulo local calculs.js en CommonJS. ¿Sintaxis correcta?

require('calculs') sin ./ ni extensión import calculs from 'calculs' sin ruta Copiar-pegar el código del módulo en cada uso require('./calculs') con ./ para la ruta local

Módulo local = ruta en ./ o ../; nombre solo = nativo (fs) o paquete npm.

1.3 · Aplicación

8. Salim arranca un proyecto nuevo y quiere la sintaxis estándar (igual que en front). ¿Elección?

Mezclar require e import en cada archivo Activar los ES Modules ("type": "module") y escribir en export/import No usar módulos en absoluto Quedarse en CommonJS por nostalgia sin motivo

ESM = estándar del lenguaje, coherente front/back, recomendado para un proyecto nuevo.

1.3 · Arbitraje

9. El proyecto de Salim mezcla require e import en el mismo archivo y falla. ¿Arbitraje?

Renombrar los archivos al azar hasta que funcione Elegir un sistema por archivo según la config y convertir limpiamente (extensión ESM explícita) Abandonar los módulos y devolverlo todo a un archivo Añadir aún más mezclas para compensar

Un sistema por archivo: la config decide, no se mezcla sin explicarlo.

1.4 · Recuerdo

10. ¿Qué hay que versionar en Git para un proyecto Node?

node_modules únicamente, el resto es inútil Los secretos .env para compartirlos con el equipo Nada en absoluto, todo se regenera siempre El código + package.json + package-lock.json (nunca node_modules)

La receta (json + lock) se versiona; node_modules se regenera vía npm install.

1.4 · Aplicación

11. Salim instala una herramienta de reinicio útil solo en desarrollo. ¿Comando?

Copiar la herramienta a mano en node_modules npm install -D nodemon (devDependency, solo dev) Añadir la herramienta en .gitignore en lugar de instalarla npm install nodemon en dependencies de producción

-D marca los paquetes de dev: necesarios en el equipo, no en producción.

1.4 · Arbitraje

12. Antes de entregar, npm audit señala una vulnerabilidad en una dependencia. ¿Arbitraje?

Entregar igualmente, ya se verá más tarde Eliminar el lock para silenciar la alerta Actualizar la dependencia afectada, probar y luego entregar — sin versionar nunca .env Versionar node_modules para «congelar» el problema

Las dependencias son un vector de ataque real: auditoría → actualización → prueba → entrega.

¿Y ahora qué?

Puntuación ≥ 80 %: pase al Nivel 2 V3 (módulos nativos fs/path/os, EventEmitter, streams y primer servidor HTTP — los bloques de sistema de Node).
Puntuación entre 50 % y 80 %: repase las secciones falladas (JS moderno 1.1, asincronía 1.2, módulos 1.3, npm 1.4), relea las explicaciones anteriores y vuelva a hacer el test.
Puntuación < 50 %: reinicie el nivel desde el principio ejecutando cada fragmento con node — la asincronía (1.2) merece una segunda lectura completa.