Comment j'ai résolu l'erreur EINVAL : readlink dans Next.js quand le projet vit sur OneDrive

Si vous travaillez avec Next.js sur Windows et que vous avez votre dépôt dans OneDrive, tôt ou tard vous pourriez croiser ce classique : EINVAL : invalid argument, readlink en essayant de lancer npm run dev.

Cela m'est arrivé et je l'ai résolu avec une approche très simple : identifier la cause réelle (verrous + liens étranges/symlinks dans .next), nettoyer en toute sécurité et ensuite prévenir pour ne plus perdre de temps.

## Ce qui se passe réellement

Lorsque OneDrive synchronise un dossier de projet, il peut :

• • verrouiller des fichiers pendant que Next compile
• • “toucher” les métadonnées des fichiers/dossiers
• • et, dans certains cas, laisser des artefacts incohérents dans .next (qui est un répertoire volatil et à forte rotation).

Résultat : Next tente d'effectuer un readlink (lire un lien symbolique/junction) et Windows renvoie EINVAL.

## Ma revue du plan (ce qui est correct et ce que j'ajouterais)

Votre plan de base est correct et minimaliste :

1. Tuer les processus Node pour libérer les verrous.
2. Supprimer .next (artefacts corrompus).
3. Supprimer tsconfig.tsbuildinfo pour forcer une recompilation propre.
4. Vérifier que le serveur de développement atteint “Ready” et compile les routes.

Ce que j'ajoute pour le rendre “pérenne” :

• • Empêcher OneDrive de synchroniser .next (idéal) ou déplacer directement le dépôt hors de OneDrive.
• • Si vous avez besoin de OneDrive par politique d'entreprise : au moins exclure le dossier du projet ou utiliser un emplacement local non synchronisé et synchroniser uniquement les fichiers docs/exports.
• • Si l'équipe est grande : laisser un runbook (étapes + commandes + critères de succès) pour que n'importe qui puisse l'exécuter.

## Étapes exactes que j'utilise pour le réparer

Objectif : revenir à un état déterministe avant de lancer dev.

### 1) Terminer les processus qui bloquent les fichiers

Sur Windows, le plus pratique est de fermer les terminaux et de tuer les processus node.exe actifs.

### 2) Nettoyage sécurisé des artefacts

Je supprime :

• • .next/
• • tsconfig.tsbuildinfo (s'il existe)

### 3) Lancer dev et confirmer “Ready”

Mon critère de succès n'est pas “ça a démarré”, c'est de voir le log avec :

• • ✓ Starting...
• • ✓ Ready in Xs
• • et qu'il commence à compiler les routes sans retomber dans EINVAL.

## Preuve de vérification (ce que je m'attends à voir)

Un exemple typique d'un “état sain” ressemble à ceci :

```text

▲ Next.js 15.1.0

• • Local: http://localhost:3000

✓ Starting...

✓ Ready in 7.4s

○ Compiling /src/middleware ... ✓ Compiled /src/middleware ... ○ Compiling /[locale]/contenidos ...

```

Avec cela, pour moi, l'erreur est résolue.

## Comment j'évite que cela se reproduise

Si vous voulez ma recommandation directe et sans détour :

• 1. Ne gardez pas le dépôt dans OneDrive (meilleure option).
• 2. Si vous ne pouvez pas l'éviter :
• • Exclure .next de la synchronisation (si votre OneDrive/IT le permet)
• • ou travailler dans un dossier local non synchronisé et pousser les changements par Git comme il se doit.

.next n'est pas du “code source”, ce sont des déchets utiles : si OneDrive interfère, cela brise votre cycle de développement.

## Si vous le souhaitez, je peux le sécuriser complètement avec vous

Quand ce type d'erreur apparaît une fois, c'est généralement la pointe de l'iceberg : chemins longs, watchers, permissions, cache corrompu, CI différent du local, etc.

Si vous voulez que je le rende stable (local + CI) et avec une checklist reproductible, demandez-moi un diagnostic.