Examen niveau 1 — Node.js

Examen — questions inédites

12 questions pour valider JavaScript & bases Node : JS moderne, asynchrone, modules CommonJS/ESM et gestion de projet npm.
Répondez à tout, puis cliquez sur Corriger : score et explications s'affichent.

1.1 · Rappel

1. Quel réflexe adopter pour déclarer les variables en JavaScript moderne ?

const par défaut, let si réassignation, jamais var var partout, comme avant let partout, jamais const Ne plus déclarer de variables du tout

const par défaut (référence stable, portée de bloc), let si la valeur évolue, var banni.

1.1 · Application

2. Salim veut les noms des utilisateurs actifs à partir d'un tableau users. Écriture moderne ?

users.filter(u => u.actif).map(u => u.nom) Une boucle for avec index et push manuels Copier chaque nom à la main dans un nouveau tableau Trier le tableau puis prendre les premiers éléments

filter garde (les actifs), map transforme (leurs noms) : l'intention se lit d'un coup d'œil.

1.1 · Arbitrage

3. Salim relit const config = { port: 3000 } puis config.port = 4000. Arbitrage ?

C'est interdit : const rend l'objet immuable, le code plantera Il faut repasser la variable en var pour la modifier C'est valide : const empêche la réassignation, pas la modification du contenu Il faut recréer tout l'objet à chaque changement de champ

const protège la « boîte » (la référence), pas son contenu : modifier un champ reste possible.

1.2 · Rappel

4. Que fait await dans une fonction async ?

Il transforme l'opération en code synchrone classique Il ignore les erreurs de l'opération Il attend le résultat sans bloquer, le code se lit dans l'ordre Il bloque tout le programme comme un sleep

await suspend la fonction en attendant la Promise sans bloquer la boucle d'événements.

1.2 · Application

5. Le console.log de Salim affiche undefined juste après un appel asynchrone. Cause ?

console.log ne fonctionne pas avec les fichiers Le fichier lu est forcément vide Node.js est cassé, il faut le réinstaller Il lit le résultat trop tôt : l'opération n'est pas encore terminée

Lancer n'est pas obtenir : le résultat arrive plus tard (callback, .then() ou await).

1.2 · Application

6. Salim enchaîne trois opérations dépendantes (fichier → base → API). Écriture recommandée ?

Trois await ordonnés dans une fonction async avec try/catch Trois lectures synchrones bloquantes en série Un setTimeout arbitraire entre chaque opération Trois callbacks imbriqués en pyramide

async/await : le code se lit dans l'ordre, sans bloquer, erreurs gérées au même endroit.

1.3 · Application

7. Salim importe son module local calculs.js en CommonJS. Syntaxe correcte ?

require('calculs') sans ./ ni extension import calculs from 'calculs' sans chemin Copier-coller le code du module à chaque usage require('./calculs') avec ./ pour le chemin local

Module local = chemin en ./ ou ../ ; nom seul = natif (fs) ou paquet npm.

1.3 · Application

8. Salim démarre un nouveau projet et veut la syntaxe standard (même qu'en front). Choix ?

Mélanger require et import dans chaque fichier Activer les ES Modules ("type": "module") et écrire en export/import Ne pas utiliser de modules du tout Rester en CommonJS par nostalgie sans raison

ESM = standard du langage, cohérent front/back, recommandé pour un nouveau projet.

1.3 · Arbitrage

9. Le projet de Salim mélange require et import dans le même fichier et plante. Arbitrage ?

Renommer les fichiers au hasard jusqu'à ce que ça passe Choisir un système par fichier selon la config et convertir proprement (extension ESM explicite) Abandonner les modules et tout remettre dans un fichier Ajouter encore plus de mélanges pour compenser

Un système par fichier : la config décide, on ne mélange pas sans l'expliquer.

1.4 · Rappel

10. Que faut-il versionner dans Git pour un projet Node ?

node_modules uniquement, le reste est inutile Les secrets .env pour les partager avec l'équipe Rien du tout, tout se régénère toujours Le code + package.json + package-lock.json (jamais node_modules)

La recette (json + lock) se versionne ; node_modules se régénère via npm install.

1.4 · Application

11. Salim installe un outil de redémarrage utile uniquement en développement. Commande ?

Copier l'outil à la main dans node_modules npm install -D nodemon (devDependency, dev seulement) Ajouter l'outil dans .gitignore au lieu de l'installer npm install nodemon en dependencies de production

-D marque les paquets de dev : nécessaires au poste, pas en production.

1.4 · Arbitrage

12. Avant de livrer, npm audit signale une vulnérabilité dans une dépendance. Arbitrage ?

Livrer quand même, on verra plus tard Supprimer le lock pour faire taire l'alerte Mettre à jour la dépendance concernée, tester, puis livrer — sans jamais versionner .env Versionner node_modules pour « figer » le problème

Les dépendances sont un vecteur d'attaque réel : audit → mise à jour → test → livraison.

Et après ?

Score ≥ 80 % : passez au Niveau 2 V3 (modules natifs fs/path/os, EventEmitter, streams et premier serveur HTTP — les briques système de Node).
Score entre 50 % et 80 % : reprenez les sections ratées (JS moderne 1.1, asynchrone 1.2, modules 1.3, npm 1.4), relisez les explications ci-dessus, puis refaites le test.
Score < 50 % : recommencez le niveau depuis le début en exécutant chaque snippet avec node — l'asynchrone (1.2) mérite une seconde lecture complète.