::: image :::

Mais aussi pour le développeur, qui délègue l'authentification à GitHub. Pourtant, beaucoup de développeurs utilisent OAuth sans réellement comprendre ce qu'il se passe derrière.

Votre application ne connaît jamais le mot de passe GitHub de l'utilisateur. À la place, elle laisse GitHub vérifier son identité, puis récupère uniquement les informations dont elle a besoin.

C'est tout le principe d'OAuth : déléguer l'authentification à un service tiers.

Implémenter Github Connect

Créer une OAuth App

La première étape consiste à créer une application sur GitHub.

Pour cela, rendez-vous dans les paramètres de votre compte, puis dans Developer settings > OAuth Apps.

::: image ::: Vous devrez notamment renseigner :

• le nom de votre application ;
• son URL ;
• une URL de callback.

Par exemple :

http://localhost:3000/auth/github/callback

Une fois l'application créée, GitHub vous fournit deux informations importantes :

Client ID
Client Secret

Le Client ID identifie votre application.

Le Client Secret, lui, est confidentiel.

Il ne doit jamais être envoyé au navigateur ni intégré dans votre code frontend.

Astuce

Vous pouvez créer autant d’application que vous voulez, donc il est au moins recommandé d’en créer une pour votre environnement de production, et une pour le local.

Vous pouvez l’appeler “MonApp (local)” par exemple.

Rediriger l'utilisateur vers GitHub

Lorsque l'utilisateur clique sur "Se connecter avec GitHub", votre application ne tente pas de l'authentifier elle-même.

Elle le redirige simplement vers GitHub.

Par exemple :

const params = new URLSearchParams({
  client_id: process.env.GITHUB_CLIENT_ID,
  redirect_uri: "http://localhost:3000/auth/github/callback",
  scope: "read:user user:email",
  state: crypto.randomUUID(),
});

response.redirect(
  `https://github.com/login/oauth/authorize?${params}`
);

Le paramètre scope indique les informations que votre application souhaite récupérer.

Le paramètre state est un identifiant aléatoire permettant de protéger le flux contre certaines attaques. Il doit être enregistré avant la redirection puis vérifié lorsque GitHub renvoie l'utilisateur.

GitHub authentifie l'utilisateur

L'utilisateur arrive alors sur GitHub et s'il n'est pas déjà connecté, GitHub lui demande de s'authentifier.

GitHub lui affiche ensuite les permissions demandées par votre application et lui demande de les accepter. Votre application ne voit jamais cette étape.

Elle attend simplement que GitHub renvoie l'utilisateur vers l'URL de callback.

::: image :::

Récupérer un code temporaire

Une fois les permissions acceptées, GitHub redirige le navigateur vers votre callback.

L'URL ressemble à ceci :

/auth/github/callback?code=...&state=...

Le code est un identifiant temporaire. À lui seul, il ne permet pas d'appeler l'API GitHub.

Votre serveur doit d'abord l'échanger contre un Access Token.

const tokenResponse = await fetch(
  "https://github.com/login/oauth/access_token",
  {
    method: "POST",
    headers: {
      Accept: "application/json",
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      client_id: process.env.GITHUB_CLIENT_ID,
      client_secret: process.env.GITHUB_CLIENT_SECRET,
      code,
    }),
  }
);

const { access_token } = await tokenResponse.json();

Cette requête doit toujours être effectuée côté serveur, car elle utilise votre Client Secret.

Récupérer l'email de l'utilisateur

Une fois le token obtenu, vous pouvez appeler l'API GitHub, par exemple pour récupérer les adresses email du compte :

const emailsResponse = await fetch(
  "https://api.github.com/user/emails",
  {
    headers: {
      Authorization: `Bearer ${access_token}`,
      Accept: "application/vnd.github+json",
    },
  }
);

const emails = await emailsResponse.json();

const primaryEmail = emails.find(
  (email) => email.primary && email.verified
)?.email;

L'adresse email principale est généralement le meilleur identifiant à utiliser.

En effet, si un utilisateur possède déjà un compte créé avec Google ou avec un email et un mot de passe, il est probable que cette adresse soit la même.

Cela permet de proposer plusieurs méthodes de connexion tout en conservant un seul compte utilisateur.

Générer le JWT de votre application

À ce stade, GitHub a terminé son travail, votre application connaît désormais l'identité de l'utilisateur.

Il ne reste plus qu'à rechercher un utilisateur possédant cette adresse email.

• S'il n'existe pas encore, vous pouvez lui créer un compte automatiquement.
• Sinon, on récupère simplement ses infos dans la base de données

Une fois cette étape terminée, vous générez votre propre token JWT :

const token = jwt.sign(
  {
    userId: user.id,
    email: user.email,
  },
  process.env.JWT_SECRET,
  {
    expiresIn: "7d",
  }
);

Ce JWT est ensuite renvoyé au navigateur, généralement dans un cookie sécurisé ou dans la réponse de votre API.

Le token GitHub sert uniquement à communiquer avec GitHub. Une fois l'utilisateur authentifié, c'est votre propre JWT qui permettra de l'identifier sur votre application.

Le fonctionnement résumé

Même si OAuth peut sembler impressionnant au premier abord, le mécanisme est finalement assez simple :

1. Votre application redirige l'utilisateur vers GitHub.
2. GitHub vérifie son identité et renvoie un code temporaire.
3. Votre serveur échange ce code contre un token, récupère l'adresse email de l'utilisateur, puis génère son propre JWT.
4. Au final, GitHub ne fait qu'une seule chose : confirmer l'identité de l'utilisateur.

Toute la gestion des comptes, des permissions et de l'authentification au sein de votre application reste sous votre responsabilité.

L'objectif était simple : distribuer une application sans demander à l'utilisateur d'installer Node.js.

Depuis sa version 18.16 (LTS), Node.js propose les Single Executable Applications (SEA), un mécanisme permettant d'intégrer une application directement dans un exécutable Node.

Cette fonctionnalité a récemment franchi une nouvelle étape (depuis la 25.5) avec l'arrivée de la commande --build-sea, qui permet de générer un exécutable directement depuis la ligne de commande, sans passer par des outils externes.

Autrement dit : Node.js sait désormais produire lui-même un exécutable.

Comment faire

Il suffit de fournir un fichier de configuration JSON (ici sea-config.json) décrivant votre application.

Par exemple :

{
  "main": "./dist/index.js",
  "output": "./mon-application"
}

Puis de lancer :

node --build-sea sea-config.json

Node.js génère alors un exécutable contenant à la fois le runtime et votre application.

Pourquoi est-ce une bonne nouvelle ?

Le principal avantage est la simplicité. Jusqu'à présent, il fallait souvent installer un outil supplémentaire, vérifier sa compatibilité avec votre version de Node.js et espérer qu'il continue d'être maintenu.

Avec une solution officielle, tout cela disparaît.

Vous bénéficiez d'une fonctionnalité développée directement par l'équipe Node.js, qui évoluera en même temps que le runtime.

Une fonctionnalité encore jeune

Il faut cependant garder une chose en tête : Même si cette fonctionnalité devient de plus en plus mature, elle reste marquée comme en développement actif dans la documentation officielle de Node.js.

Certaines limitations existent encore.

Par exemple, les premières versions de SEA ne supportaient que les applications CommonJS. Les versions récentes prennent désormais également en charge les modules ECMAScript (ESM), mais toutes les fonctionnalités d'un projet Node ne sont pas forcément compatibles selon votre configuration.

Si votre application dépend d'outils comme Puppeteer, de modules natifs ou de ressources externes, quelques ajustements peuvent encore être nécessaires.

Faut-il abandonner pkg ?

Pour un nouveau projet, la réponse est probablement oui.

La fonctionnalité native de Node.js a vocation à remplacer progressivement les outils historiques de packaging. Elle est mieux intégrée au runtime et ne dépend plus d'un projet tiers qui pourrait cesser d'être maintenu.

En revanche, si vous possédez déjà une chaîne de build basée sur pkg et qu'elle fonctionne parfaitement, il n'y a pas forcément d'urgence à la modifier.

À noter

Node ne "compile" pas votre code JavaScript vers du code machine. Il embarque votre application dans un exécutable Node existant, qui est lui-même spécifique à un système d'exploitation et à une architecture (Windows, Linux, macOS, x64, ARM64, etc.).

Pendant longtemps, il suffisait d'utiliser son adresse email et son mot de passe. Mais aujourd'hui, cette méthode ne fonctionne plus.

Google bloque désormais l'accès aux comptes Gmail depuis la plupart des applications utilisant simplement un mot de passe classique.

Heureusement, Google propose une solution : les App Passwords, ou mots de passe d'application.

Qu'est-ce qu'un App Password ?

Un App Password est un mot de passe généré par Google spécialement pour une application.

Contrairement à votre mot de passe principal :

• il est limité à un usage précis
• il peut être révoqué à tout moment
• il n'autorise pas l'accès complet à votre compte Google

L'idée est de permettre à une application de se connecter à Gmail sans lui donner votre véritable mot de passe.

Générer un App Password

Activer l'authentification à deux facteurs

Avant de pouvoir créer un App Password, vous devez activer la validation en deux étapes sur votre compte Google.

Rendez-vous dans les paramètres de sécurité de votre compte Google puis activez l'authentification à deux facteurs.

Sans cette étape, le menu des App Passwords n'apparaîtra pas.

Créer un mot de passe

Une fois l'authentification à deux facteurs activée :

• ouvrez les paramètres de sécurité Google
• recherchez la section "Mots de passe des applications"
• créez un nouveau mot de passe
• choisissez un nom comme "Serveur SMTP" ou "Application NodeJS"

Vous pouvez aussi cliquer sur le lien direct : https://myaccount.google.com/apppasswords

Google génère alors une chaîne ressemblant à ceci :

abcd efgh ijkl mnop

C'est ce mot de passe qu'il faudra utiliser dans votre application.

Utiliser votre App Password

Configuration SMTP

Pour envoyer des emails avec Gmail, utilisez les paramètres suivants :

Serveur SMTP : smtp.gmail.com
Port : 587
Sécurité : TLS / STARTTLS
Utilisateur : <votre-adresse@gmail.com>
Mot de passe : <votre_app_password>

Configuration IMAP

Si vous souhaitez recevoir ou lire des emails, vous devrez utiliser IMAP.

Les paramètres sont les suivants :

Serveur IMAP : imap.gmail.com
Port : 993
Sécurité : SSL/TLS
Utilisateur : votre-adresse@gmail.com
Mot de passe : <votre_app_password>

Les limites de Gmail

Même si Gmail fonctionne très bien pour des tests ou de petits projets, il ne remplace pas un véritable service d'envoi transactionnel.

Google applique notamment :

• des limites d'envoi quotidiennes
• des contrôles anti-spam
• des restrictions sur certains usages automatisés

Pour un projet professionnel ou une application à fort volume, des solutions comme Brevo (français), Resend, Mailgun ou SendGrid seront généralement plus adaptées.

Notre article dédié pour l’envoi d’email en Node.js

Mais il existe aussi beaucoup de cas où l’on veut faire l’inverse : lire les emails reçus.

Par exemple, pour traiter automatiquement des demandes entrantes, récupérer des pièces jointes, analyser des réponses clients, ou déclencher une action lorsqu’un message arrive dans une boîte spécifique.

Pour cela, on utilise généralement un protocol dédié : IMAP (Internet Message Access Protocol).

IMAP permet à une application de se connecter à une boîte mail pour lire, parcourir et manipuler les messages.

En Node.js, deux bibliothèques sont particulièrement pratiques pour ce besoin : ImapFlow et MailParser.

ImapFlow est un client IMAP moderne pour Node.js, avec une API basée sur les Promises et async/await (documentation officielle).

MailParser, de son côté, permet de transformer un email brut en objet JavaScript exploitable. Sa fonction simpleParser est pratique pour les cas simples, tandis que la classe MailParser permet de traiter les gros messages sous forme de streams (documentation officielle).

Fonctionnement

Installer les dépendances

On commence par installer les deux packages :

npm install imapflow mailparser

Si vous utilisez TypeScript, ImapFlow fournit déjà ses propres types. Pour MailParser, vous pouvez ajouter :

npm install -D @types/mailparser

Se connecter à une boîte mail

Voici un exemple avec Gmail, mais le principe est le même avec n’importe quel serveur IMAP.

import { ImapFlow } from "imapflow";

const client = new ImapFlow({
  host: "imap.gmail.com",
  port: 993,
  secure: true,
  auth: {
    user: "votre-adresse@gmail.com",
    pass: "votre-app-password",
  },
});

await client.connect();

Pour Gmail, il ne faut pas utiliser votre mot de passe principal.

Il faut générer un App Password depuis votre compte Google, puis l’utiliser comme mot de passe IMAP.

Lire les derniers emails

Une fois connecté, il faut ouvrir une boîte. La plus courante est INBOX.

const lock = await client.getMailboxLock("INBOX");

try {
  for await (const message of client.fetch("1:*", {
    envelope: true,
    source: true,
  })) {
    console.log(message.envelope.subject);
  }
} finally {
  lock.release();
}

Le lock évite que plusieurs opérations entrent en conflit sur la même boîte.

C’est une bonne habitude avec ImapFlow : on verrouille, on travaille, puis on libère.

Ici, source: true permet de récupérer l’email brut. C’est ce contenu que nous allons ensuite donner à MailParser.

Parser un email avec MailParser

Un email n’est pas un simple texte. Il peut contenir du HTML, du texte brut, des pièces jointes, des encodages différents, des headers, des destinataires, etc.

MailParser s’occupe de transformer tout cela en objet plus facile à manipuler :

import { simpleParser } from "mailparser";

for await (const message of client.fetch("1:*", {
  envelope: true,
  source: true,
})) {
  const parsed = await simpleParser(message.source);

  console.log({
    subject: parsed.subject,
    from: parsed.from?.text,
    text: parsed.text,
    html: parsed.html,
  });
}

simpleParser charge le message en mémoire.

C’est très pratique pour démarrer, mais si vous traitez de gros emails ou beaucoup de pièces jointes, il faudra plutôt utiliser l’API en streaming de MailParser.

Lire uniquement les emails non lus

Dans la vraie vie, vous ne voulez pas relire toute la boîte à chaque exécution.

Vous pouvez chercher uniquement les emails non lus :

for await (const message of client.fetch(
  { seen: false },
  { envelope: true, source: true }
)) {
  const parsed = await simpleParser(message.source);

  console.log(parsed.subject);
}

Ensuite, vous pouvez marquer le message comme lu :

await client.messageFlagsAdd(message.uid, ["\\Seen"], { uid: true });

Cela permet de construire facilement un petit worker qui traite seulement les nouveaux emails.

Exemple complet

import { ImapFlow } from "imapflow";
import { simpleParser } from "mailparser";

const client = new ImapFlow({
  host: "imap.gmail.com",
  port: 993,
  secure: true,
  auth: {
    user: process.env.MAIL_USER,
    pass: process.env.MAIL_PASSWORD,
  },
});

await client.connect();

const lock = await client.getMailboxLock("INBOX");

try {
  for await (const message of client.fetch(
    { seen: false },
    { uid: true, source: true }
  )) {
    const parsed = await simpleParser(message.source);

    console.log("Sujet :", parsed.subject);
    console.log("De :", parsed.from?.text);
    console.log("Texte :", parsed.text);

    await client.messageFlagsAdd(message.uid, ["\\Seen"], { uid: true });
  }
} finally {
  lock.release();
  await client.logout();
}

• écouter des évènements du navigateur
• gérer des états réactifs
• accéder aux APIs Web
• nettoyer des listeners

C’est précisément le problème que résout VueUse.

Une bibliothèque de composables

VueUse est une immense bibliothèque de composables prêts à l’emploi pour Vue.js.

Elle propose des centaines d’utilitaires pour :

• le navigateur
• les animations
• les capteurs
• les raccourcis clavier
• le stockage local
• les APIs Web modernes

Et surtout tous les utilitaires sont pensés pour fonctionner naturellement avec la réactivité de Vue.

L’installation est très simple :

npm install @vueuse/core

Ensuite, vous pouvez importer uniquement les composables dont vous avez besoin.

Copier du texte avec useClipboard

L’API du presse-papiers du navigateur peut être un peu pénible à utiliser directement.

VueUse simplifie énormément cela avec useClipboard.

import { useClipboard } from "@vueuse/core"

const { copy, copied } = useClipboard()

const copyCode = async () => {
  await copy("Hello world")
}

Le booléen copied devient automatiquement true pendant quelques secondes après la copie.

Parfait pour afficher un message :

<p v-if="copied">Texte copié !</p>

C’est idéal pour :

• des boutons “Copier”
• des snippets de code
• des liens de partage
• des tokens API

Récupérer la position GPS avec useGeolocation

VueUse propose aussi un accès très simple à la géolocalisation du navigateur.

import { useGeolocation } from "@vueuse/core"

const { coords, locatedAt, error } = useGeolocation()

Les coordonnées deviennent automatiquement réactives :

<p>Latitude : {{ coords.latitude }}</p>
<p>Longitude : {{ coords.longitude }}</p>

C’est particulièrement utile pour :

• une carte interactive
• une application météo
• du contenu localisé
• du suivi de position

Et contrairement à une implémentation manuelle, VueUse gère déjà :

• les listeners
• la réactivité
• le nettoyage automatique

Détecter l’état du réseau avec useNetwork

Savoir si un utilisateur est hors ligne peut améliorer énormément l’expérience utilisateur.

Avec useNetwork :

import { useNetwork } from "@vueuse/core"

const { isOnline, downlink, effectiveType } = useNetwork()

Vous pouvez facilement afficher un message :

<p v-if="!isOnline">
  Vous êtes actuellement hors ligne.
</p>

Mais aussi adapter l’application selon la qualité du réseau.

Par exemple :

• réduire la qualité des images
• désactiver certaines animations
• éviter des requêtes lourdes

Utiliser une manette avec useGamepad

C’est probablement l’un des composables les plus amusants.

useGamepad permet d’accéder aux manettes connectées au navigateur.

import { useGamepad } from "@vueuse/core"

const { gamepads } = useGamepad()

Vous pouvez ensuite lire les boutons et axes :

<pre>{{ gamepads }}</pre>

Cela ouvre la porte à énormément de projets :

• mini jeux Vue.js
• interfaces interactives
• bornes tactiles
• contrôles alternatifs

Et tout cela avec très peu de code.

À chaque modification du module, il faudrait normalement :

• publier une nouvelle version
• réinstaller le package dans le projet de test
• relancer l’application

Heureusement, npm link existe justement pour éviter ça.

Fonctionnement

Cette commande permet de créer un lien symbolique entre un package local et un autre projet.

Autrement dit : votre projet utilise directement le code source local du module, comme s’il avait été installé depuis NPM.

Le fonctionnement se fait en deux étapes. D’abord, dans le dossier du paquet NPM :

npm link

Cette commande enregistre le package globalement sur votre machine.

Ensuite, dans le projet qui doit utiliser ce package :

npm link nom-du-package

À partir de ce moment-là, le dossier node_modules du projet pointera directement vers votre module local.

Un lien symbolique

Le gros avantage, c’est que les modifications deviennent quasiment instantanées. Vous changez du code dans votre package… et votre projet de test utilise immédiatement la nouvelle version.

Plus besoin de publier une version 0.0.1-dev-test-42.

Sous le capot, npm link utilise des liens symboliques (symlink) du système d’exploitation.

Un exemple concret

Voici un exemple pour bien comprendre la marche à suivre. Vous avez deux projets :

mon-package/
mon-app/

!!! well Dans mon-package :

npm link

!!! !!! well Puis dans mon-app :

npm link mon-package

!!!

Et voilà. Votre application utilise maintenant directement la version locale du package.

• Pourquoi ce framework a été choisi ?
• Pourquoi ce calcul fonctionne de cette manière ?
• Pourquoi utilise-t-on Redis ici, mais pas ailleurs ?

Le problème, c’est qu’avec le temps, les développeurs changent, les discussions Slack disparaissent, et les décisions prises plusieurs mois auparavant deviennent difficiles à comprendre.

C’est précisément le rôle des ADR, pour Archicture Decision Record.

Architecture Decision Record

Un ADR est un document très simple qui sert à conserver une trace d’une décision technique importante dans un projet.

L’idée n’est pas de rédiger une énorme documentation, au contraire :

Un ADR est généralement court, simple et centré sur une seule décision.

L’objectif est surtout de répondre à une question essentielle : Pourquoi cette décision a-t-elle été prise ?

Un ADR contient souvent :

• le contexte ⇒ explique le problème rencontré.
• la décision ⇒ décrit le choix effectué.
• les conséquences ⇒ détaillent les avantages, limites ou compromis associés.

Voici un exemple très simplifié :

# ADR-001 : Utilisation de PostgreSQL

## Context
Le projet nécessite des relations complexes entre les données.

## Decision
Utiliser PostgreSQL comme base principale.

## Consequences
- SQL puissant
- bonnes performances relationnelles
- infrastructure plus lourde qu’une base NoSQL

Ce type de document peut sembler anodin… mais il devient extrêmement précieux avec le temps.

Pourquoi mettre en place des ADR ?

Sans ADR, beaucoup de projets finissent avec des décisions “historiques” que plus personne ne comprend vraiment.

Et cela crée souvent des problèmes :

• duplication de solutions
• remise en question permanente
• peur de modifier certaines parties du projet
• onboarding plus difficile

Et surtout cela rend encore plus critique le fameux “bus factor”

Mettre en place des ADR est particulièrement utile dans :

• les projets longs
• les équipes qui grandissent
• les architectures complexes
• les projets open source

La bonne nouvelle, c’est qu’on peut commencer, dès aujourd’hui, sans aucun outils

Beaucoup d’équipes stockent simplement leurs ADR dans un dossier :

/docs/adr

Ou directement :

/adr

Le plus important n’est pas le format, mais de commencer à documenter le plus tôt possible.

Parce qu’en architecture logicielle, le problème n’est pas seulement de prendre de bonnes décisions. C’est aussi de comprendre, plusieurs années plus tard, pourquoi elles ont été prises.

Elles peuvent sembler similaires… mais elles n’ont absolument pas le même rôle.

À noter que si vous ne connaissez pas Docker, cet article ne vous sera pas très utile, mais vous pouvez toujours aller écouter notre introduction à Docker dans un épisode dédié du podcast !

La commande RUN

RUN est utilisé lors de la construction de l’image Docker.

Par exemple :

RUN apt-get update && apt-get install -y curl

Cette commande est exécutée :

• pendant le docker build
• pour modifier l’image

RUN sert à préparer l’image.

Chaque instruction RUN crée une nouvelle couche dans l’image Docker.

Typiquement, vous utilisez RUN pour :

• installer des dépendances
• copier ou générer des fichiers
• configurer l’environnement

La commande CMD

CMD est utilisée lors du lancement du conteneur.

Par exemple :

CMD ["node", "server.js"]

Cette commande est exécutée :

• quand vous faites docker run
• au démarrage du conteneur

CMD sert à dire : “voilà ce que fait ce conteneur quand il démarre”.

La différence clé

La différence principale tient en une phrase : RUN s’exécute pendant le build tandis que CMD s’exécute au runtime.

Autrement dit :

• RUN modifie l’image
• CMD définit le comportement du conteneur

Un exemple concret

Prenons un Dockerfile simple :

FROM node:18
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .

CMD ["node", "index.js"]

Ce qu’il se passe :

1. RUN npm install installe les dépendances dans l’image
2. CMD ["node", "index.js"] lance l’application au démarrage

Sans CMD, le conteneur ne ferait rien.

Pour aller plus loin

CMD peut être remplacé

Par exemple :

docker run mon-image echo "Hello"

Ici :

• CMD est ignoré
• la commande echo "Hello" est exécutée

CMD est une valeur par défaut.

Le système de couches (layers)

Chaque RUN ajoute une couche à votre image.

Par exemple :

RUN apt-get update
RUN apt-get install -y curl

Crée deux couches.

Les différentes couches sont utilisées par Docker pour optimiser la mémoire utilisée par les images, car les couches similaires sont partagées entre les différents conteneurs !

Résumé de l'article

RUN et CMD sont complémentaires.

• utilisez RUN pour construire votre environnement (exécuté pendant le build)
• utilisez CMD pour lancer votre application (exécuté au runtime)

Si vous les confondez, votre conteneur ne fera probablement pas ce que vous attendez.

un git reset.

Vous revenez en arrière, vous changez d’état, vous annulez un commit ou vous bougez votre branche… et là, en regardant votre projet, vous vous retrouvez avec plein de fichiers qui traînent.

Parfois ce sont :

• des fichiers générés
• des dossiers de build
• des fichiers temporaires
• des morceaux d’un ancien état du projet

Et dans git status, vous voyez apparaître une longue liste de fichiers “nouveaux”.

Git ne les a pas supprimés, parce qu’ils ne font pas partie des fichiers suivis à cet instant. Mais si vous souhaitez vous en débarasser (autrement qu’en supprimant tout à la main), voilà comment faire !

La bonne commande : git clean

Pour supprimer les fichiers non suivis, Git propose cette commande :

git clean -f

Cette commande supprime les fichiers non suivis du dossier courant.

Mais attention :

git clean est une commande destructive.

Une fois les fichiers supprimés, Git ne pourra pas les restaurer.

Le mode simulation

Avant de lancer une suppression, le bon réflexe est d’utiliser :

git clean -n

Le -n signifie dry run. C’est probablement l’option la plus importante de toute la commande.

Git affiche ce qu’il supprimerait, sans réellement le faire. Si vous avez beaucoup de fichiers apparus après un git reset, commencez toujours par là.

Supprimer les dossiers

Par défaut, git clean ne supprime pas les dossiers non suivis.

Or après un reset, ce sont souvent justement des dossiers entiers qui traînent :

• dist/
• build/
• .cache/
• anciens dossiers générés

Pour inclure les dossiers, utilisez :

git clean -fd

• f pour forcer
• d pour inclure les répertoires

Dans beaucoup de cas, après un git reset, c’est cette commande qu’on cherche vraiment.

Inclure les fichiers ignorés par .gitignore

Il y a un autre cas fréquent.

Vous faites un reset, puis vous voulez repartir d’un projet vraiment propre.

Mais certains fichiers sont ignorés par Git via .gitignore :

• dossiers de build
• fichiers d’environnement
• caches
• dépendances générées

Par défaut, git clean ne les supprime pas.

Si vous voulez aussi supprimer ces fichiers ignorés, il faut utiliser :

git clean -fdx

Cette commande supprime :

• les fichiers non suivis
• les dossiers non suivis
• les fichiers ignorés par .gitignore

Elle est très utile pour remettre un projet dans un état vraiment propre.

Mais elle doit être utilisée avec une grande prudence.

Supprimer UNIQUEMENT les fichiers ignorés

Pour ne supprimer que les fichiers présents dans .gitignore ,on utilise le paramètre -X (à ne pas confondre avec -x) :

git clean -fdX

Supprime uniquement les fichiers ignorés

Conclusion

Retenez surtout ceci :

• git clean -n permet de vérifier avant
• git clean -fd supprime fichiers + dossiers
• git clean -fdx fait le ménage complet

npm install

Cette commande semble anodine. Elle télécharge simplement les dépendances listées dans le package.json.

Mais en réalité, npm peut aussi exécuter du code pendant l’installation.

Beaucoup de développeurs l’ignorent, mais certains packages contiennent des scripts qui s’exécutent automatiquement lors de l’installation. Et dans certains cas, ces scripts peuvent poser problème : comportements inattendus, téléchargements lourds… ou pire, scripts malveillants.

Heureusement, npm propose une option simple pour éviter cela :

npm install --ignore-scripts

Cette option empêche npm d’exécuter les scripts définis dans les dépendances.

Les scripts exécutés automatiquement par npm

Dans un package.json, un package peut définir plusieurs scripts.

Par exemple :

{
  "scripts": {
    "postinstall": "node build.js"
  }
}

npm peut exécuter automatiquement certains scripts pendant l’installation.

Les plus courants sont :

• preinstall
• install
• postinstall
• prepare

Ces scripts sont souvent utilisés pour compiler du code natif, télécharger des binaires, générer des fichiers nécessaires au package, préparer des assets, etc…

Le problème, c’est que npm exécute ces scripts automatiquement, sans vous demander votre avis.

Le risque : exécuter du code sans le savoir

L’écosystème npm est immense. On compte aujourd’hui plus de deux millions de packages.

Et comme dans tout écosystème ouvert, il arrive que certains packages soient malveillants ou compromis.

Plusieurs incidents ont déjà eu lieu :

• des packages abandonnés repris par des acteurs malveillants
• des dépendances injectant du code espion
• des scripts envoyant des informations système

Les scripts postinstall sont particulièrement sensibles, car ils s’exécutent directement sur votre machine au moment de l’installation.

Concrètement, un script npm peut :

• accéder à votre système de fichiers
• lire des variables d’environnement
• envoyer des données vers Internet
• modifier votre configuration

En d’autres termes : un simple npm install peut exécuter du code arbitraire.

Utiliser ignore-scripts pour garder le contrôle

Pour éviter cela, npm propose une option très simple :

npm install --ignore-scripts

Avec cette commande :

• npm télécharge les dépendances
• npm les installe dans node_modules
• mais aucun script n’est exécuté

Cela bloque :

• preinstall
• install
• postinstall
• prepare

Les packages sont installés sans exécution de code externe.

⚠️ Attention : --ignore-scripts bloque absolument tous les scripts.

Il n’est pas possible de désactiver uniquement postinstall ou un script spécifique.

Si vous utilisez cette option, aucun script lifecycle ne sera exécuté, quel que soit le package.

Cette option est particulièrement utile dans plusieurs situations :

• audit de dépendances
• analyse d’un projet inconnu
• environnement sécurisé
• pipeline CI/CD
• installation de dépendances non fiables

Équivalent avec pnpm et yarn

Si vous utilisez un autre gestionnaire de paquets, sachez que des options similaires existent.

pnpm

pnpm propose exactement la même option :

pnpm install --ignore-scripts

Le comportement est identique à npm : les dépendances sont installées mais aucun script lifecycle n’est exécuté.

Yarn

Avec Yarn (v1 ou v3), l’option est également disponible :

yarn install --ignore-scripts

Comme pour npm et pnpm, cela bloque l’exécution des scripts preinstall, install et postinstall.

Autrement dit, les trois principaux gestionnaires de paquets Node.js offrent ce mécanisme de sécurité.

Réactiver les scripts si nécessaire

Si un package a réellement besoin de ses scripts pour fonctionner, vous pouvez les relancer plus tard.

Par exemple :

npm rebuild

Ou simplement relancer l’installation normalement :

npm install

L’avantage est que vous gardez le contrôle sur ce qui s’exécute sur votre machine.

Dans un écosystème aussi vaste que npm, cette petite option peut éviter de nombreux problèmes.