Front-end · 6 mondes · 18 étapes

JavaScript

Le langage du web : types, fonctions, tableaux, objets et asynchrone.

Progression

0 %

0/18 étapes terminées

← Maîtrise avancée

Avancé · 12 min de lecture

JavaScript en production

Modules, outillage, TypeScript et navigateur

1Définition

Au-delà du langage, un projet JavaScript réel repose sur des modules (import / export), un gestionnaire de paquets (npm), un linter qui attrape les pièges avant l'exécution, et de plus en plus sur TypeScript, qui ajoute des types vérifiés à la compilation.

2Principes fondamentaux

Des modules plutôt qu'un fichier géant

export function prixTTC dans un fichier, import { prixTTC } from "./prix.js" dans un autre : chaque fichier a une responsabilité.

Un linter, toujours

ESLint signale ==, les variables inutilisées, les promesses non traitées : les erreurs du monde 1 à 6, automatiquement.

TypeScript pour les projets qui durent

Une faute de type détectée à l'écriture coûte une seconde ; la même en production coûte une soirée.

Tester le comportement

Vitest ou Jest exécutent des fonctions de test à chaque modification : les fonctions pures du monde 3 se testent en une ligne.

3Exemples pratiques

Deux modules

Exemple

1// prix.js2export const prixTTC = (ht, taux = 0.2) => ht * (1 + taux);3 4// panier.js5import { prixTTC } from "./prix.js";6export const total = (articles) => articles.reduce((acc, a) => acc + prixTTC(a), 0);

Chaque fichier expose ce qu'il offre et importe ce dont il a besoin : les dépendances sont explicites.

Le même code en TypeScript

Exemple

1export const prixTTC = (ht: number, taux = 0.2): number => ht * (1 + taux);2 3prixTTC("100");   // erreur à l'écriture : string n'est pas number

L'erreur du monde 1 — un texte là où un nombre est attendu — ne peut plus atteindre la production.

4Erreurs courantes

Tout dans un fichier

À éviter

// app.js : 3 000 lignes

À faire

// un module par responsabilité

Pourquoi : Personne ne relit 3 000 lignes : les bugs y restent.

Ignorer le linter

À éviter

// eslint-disable-next-line (partout)

À faire

// corriger ce que le linter signale

Pourquoi : Chaque avertissement désactivé est un piège laissé en place.

5Subtilités à connaître

◆package-lock.json fige les versions exactes de toutes les dépendances : il se commite, toujours.
◆Le navigateur exécute directement les modules (<script type="module">), mais un outil de construction (Vite) optimise le code pour la production.
◆Une dépendance npm est du code d'un inconnu exécuté dans ton projet : moins il y en a, mieux c'est.

6Techniques d'expert

Déboguer dans le navigateur

debugger; dans le code arrête l'exécution quand les outils de développement sont ouverts : on inspecte les variables au lieu de les deviner.

Annuler une requête

AbortController interrompt un fetch devenu inutile, par exemple quand l'utilisateur quitte la page.

const controle = new AbortController();fetch("/api/profil", { signal: controle.signal });controle.abort();

Tester une fonction pure

Une fonction sans effet de bord se teste en une ligne.

import { expect, test } from "vitest";import { prixTTC } from "./prix.js"; test("prix TTC par défaut", () => {  expect(prixTTC(100)).toBe(120);});

7Sur le terrain

Ce site est écrit en TypeScript, vérifié par ESLint à chaque modification, et chaque exercice est testé automatiquement.
La plupart des pannes de front-end en production viennent de données absentes lues sans `?.` et de promesses rompues sans `catch`.
Connaître le langage sans framework est ce qui permet de passer d'un framework à l'autre sans tout réapprendre.

8Vérifie ta compréhension

Question 1/3

Score 0

À quoi sert un linter ?

Envie d'essayer ? Ouvre le Labo et recopie les exemples pour les modifier.