Caches de la chaîne d'outils JavaScript et versions de Node

La catégorie js (alias : node, npm) couvre tout ce que la chaîne d'outils JavaScript et React Native conserve en dehors de vos projets : les caches et stores des gestionnaires de paquets, les versions de Node installées par les gestionnaires de versions, les caches de Metro et Jest dans le dossier temporaire, les téléchargements d'Expo et d'EAS, et les navigateurs téléchargés pour les tests de bout en bout.

Presque tout ici peut être régénéré. Après le nettoyage, vous payez un nouveau téléchargement ou une première exécution plus lente. Le node_modules de chaque projet est un artefact de projet, traité dans Projets React Native.

Démarrage rapide

lu-cleaner scan -c js                        # ce qui prend de la place ; rien n'est modifié
lu-cleaner clean -c js                       # sélecteur : rien n'est sélectionné, appuyez sur a pour les éléments recommandés
lu-cleaner clean --yes --smart -c js --dry-run   # le plan recommandé, pour les scripts

Un scan typique (tailles données à titre d'exemple) :

JS toolchain 17.1 GB · 12 items · ★ 12.7 GB recommended NAME SIZE AGE RISK RECO Yarn Berry global cache 6.10 GB 4d safe ★ pnpm store v10 3.80 GB 2d moderate pnpm store v3 2.90 GB 7mo moderate ★ Jest cache 2.20 GB now safe ★ npm cache (_cacache) 1.30 GB now safe ★ node v22.12.0 (fnm) 190 MB 3w moderate ! pinned by 1 project file(s): ~/dev/shop-app/.nvmrc node v20.19.5 (nvm) 180 MB 2d caution ! default version: nvm default (20) node v18.20.4 (nvm) 172 MB 9mo moderate node v16.20.2 (nvm) 165 MB 1y moderate ★ npx cache · @playwright/mcp 48.0 MB 1d moderate ! used by 1 running process(es) (MCP server?) — deleting it breaks them until restarted fnm stale shell links (4210) 1.30 MB 2d safe ★ pnpm store prune ? 2d safe ★

★ marque ce que choisit la sélection intelligente ; un élément qui porte un avertissement ! n'est jamais recommandé. node v18.20.4 n'a pas de ★ alors que rien ne le référence : c'est la version nvm non référencée la plus récente, que keep_latest tient à l'écart de la sélection intelligente (voir plus bas). La taille de pnpm store prune est ?, car ce qu'il libère n'est connu qu'une fois la commande exécutée.

Vos projets continuent de fonctionner

Nettoyer le cache d'un gestionnaire de paquets ne casse pas les node_modules déjà installés : npm et Yarn v1 y copient les fichiers, pnpm et Bun utilisent des clones APFS ou des liens physiques, qui survivent à la suppression du store. La prochaine installation retélécharge simplement ce dont elle a besoin. Les exceptions sont Yarn Plug'n'Play et le store virtuel global de pnpm, décrits plus bas dans Yarn et pnpm.

Gestionnaires de paquets

npm

Élément	Emplacement	Type (-k)	Risque
Cache npm	~/.npm/_cacache	js-npm-cache	safe
Journaux de débogage npm	~/.npm/_logs	js-npm-logs	safe
Installations npx, un élément par paquet	~/.npm/_npx/<hash>	npx-package	moderate
Binaires téléchargés par des scripts postinstall (@sentry/cli, libvips de sharp, prebuild-install)	~/.npm/sentry-cli, ~/.npm/_libvips, ~/.npm/_prebuilds…	js-npm-binary-downloads	safe

npx installe chaque paquet qu'il exécute dans son propre dossier _npx/<hash>. lu-cleaner nomme ces éléments d'après le paquet (npx cache · @playwright/mcp), car ce sont souvent des serveurs MCP lancés par des outils d'IA. Une installation utilisée par un processus en cours reçoit l'avertissement used by N running process(es) (MCP server?) — deleting it breaks them until restarted ; une installation inutilisée depuis 14 jours est recommandée. Le prochain appel à npx la réinstalle.

Les installations npx placées dans un emplacement de cache personnalisé ($npm_config_cache) sont aussi trouvées.

Yarn

Élément	Emplacement	Type (-k)	Risque
Cache Yarn v1	~/Library/Caches/Yarn/v*	js-yarn-classic-cache	safe
Dossiers temporaires d'exécution de Yarn v1 (de plus d'un jour)	$TMPDIR/yarn--*	js-yarn-tmp	safe
Cache global de Yarn Berry	~/.yarn/berry/cache	yarn-berry-cache	safe, ou caution avec des projets PnP
Métadonnées du registre de Yarn Berry	~/.yarn/berry/metadata	yarn-berry-metadata	safe
Store à liens physiques de Yarn Berry	~/.yarn/berry/store (et l'ancien index)	yarn-berry-store	moderate

Le dossier global de Yarn Berry (v2+) est trouvé via $YARN_GLOBAL_FOLDER, puis globalFolder dans ~/.yarnrc.yml, puis l'emplacement par défaut ~/.yarn/berry.

• Les métadonnées contiennent les documents du registre npm mis en cache par Yarn. yarn cache clean ne les supprime pas : elles ne font donc que grossir.
• Le store à liens physiques est le store de contenu de nmMode: hardlinks-global. Les fichiers encore liés physiquement dans le node_modules d'un projet survivent à la suppression : l'espace libéré peut donc être bien inférieur à la taille affichée. Dans ce cas, la colonne de taille affiche un * et --json indique le gain réel dans reclaim.
• Mise en garde sur Plug'n'Play. Les projets qui utilisent PnP (un fichier .pnp.cjs au lieu de node_modules) lisent leurs dépendances directement dans les fichiers zip du cache global à l'exécution : pour eux, le cache est l'installation. Quand lu-cleaner trouve un tel projet dans vos racines et vos worktrees (recherchés jusqu'à max_depth, comme le fait le scanner d'artefacts), le cache global passe en caution avec l'avertissement used at runtime by N Plug'n'Play project(s): they break until yarn install (needs network), et il n'est jamais recommandé. Quand la recherche n'a pas pu regarder partout (trop de dossiers, dossiers illisibles ou exclus, racine égale à votre dossier personnel), le cache est moderate au lieu de safe.

Cache Yarn v1 ou Berry ?

Quand Corepack exécute Yarn 3 ou 4, un simple yarn cache clean peut viser le cache Berry au lieu du cache Yarn v1. lu-cleaner liste les deux séparément, pour que vous voyiez ce que contient chacun.

pnpm

pnpm conserve un store adressé par contenu pour chaque format de store : v3 pour pnpm 7 à 9, v10, v11… dans ~/Library/pnpm/store par défaut (et aussi $PNPM_HOME/store, ~/.local/share/pnpm/store, ~/.pnpm-store). lu-cleaner liste chaque store comme un élément moderate et demande à pnpm store path lequel est le store actuel.

Pour le store actuel, vous avez deux options distinctes :

Élément	Méthode	Risque	Effet
pnpm store prune	exécute pnpm store prune	safe, recommandé	supprime uniquement les paquets qu'aucun projet ne référence plus
pnpm store v10	supprime le dossier	moderate	supprime tout le store ; le prochain pnpm install retélécharge tout ce dont il a besoin

Préférez le prune pour le store que vous utilisez. Supprimer un store entier a du sens pour un format que pnpm n'utilise plus, comme le store v3 laissé après le passage à pnpm 10 : il est recommandé une fois resté inutilisé plus longtemps que stale_after. Ce que libère le prune reste inconnu tant qu'il n'a pas été exécuté : sa taille s'affiche donc comme ? et il n'ajoute rien aux totaux ; les détails donnent la taille du store entier, qui en est la borne supérieure. L'élément prune n'apparaît que si la commande pnpm fonctionne. Si vous sélectionnez les deux, la suppression du store l'emporte et le prune est retiré du plan.

Comme les node_modules installés partagent des fichiers avec le store (clones APFS ou liens physiques), supprimer un store peut libérer moins que sa taille. lu-cleaner le mesure : voir Pourquoi l'espace libéré n'apparaît pas.

Store virtuel global. Avec enableGlobalVirtualStore (pnpm 10.12+), les node_modules de vos projets sont des liens symboliques vers le dossier links/ du store. Supprimer ce store les casse jusqu'au prochain pnpm install : il passe donc en caution avec l'avertissement global virtual store used by N project(s): their node_modules break until pnpm install, et il n'est jamais recommandé. Le prune reste safe : il conserve ce qu'utilisent les projets enregistrés. Quand un projet enregistré est inaccessible (volume non monté, absence de permission), le prune n'est pas recommandé non plus : pnpm considérerait ce projet comme disparu et supprimerait ses paquets.

Le cache de métadonnées de pnpm (~/Library/Caches/pnpm, type js-pnpm-metadata-cache) est un élément safe distinct.

Bun et Corepack

Élément	Emplacement	Type (-k)	Risque
Cache d'installation de Bun	~/.bun/install/cache	js-bun-install-cache	moderate
Cache du transpileur de Bun	~/Library/Caches/bun	js-bun-transpiler-cache	safe
Installations temporaires de bunx (de plus d'un jour)	$TMPDIR/bunx-*	js-bunx-tmp	safe
Versions de Yarn et pnpm téléchargées par Corepack	~/.cache/node/corepack/*	js-corepack-cache	safe

Sur APFS, Bun clone les fichiers dans node_modules : supprimer son cache d'installation peut donc libérer bien moins que sa taille. lu-cleaner mesure les clones : la taille affiche alors un *, et --json indique le gain réel dans reclaim. Le lastKnownGood.json de Corepack est conservé.

Versions de Node

Où elles sont trouvées

Gestionnaire	Dossier des versions
nvm	~/.nvm/versions/node/ (ou $NVM_DIR)
fnm	~/.local/share/fnm/node-versions/, ~/Library/Application Support/fnm/, ~/.fnm/ (ou $FNM_DIR)
mise	~/.local/share/mise/installs/node/ (ou $MISE_DATA_DIR)
asdf	~/.asdf/installs/nodejs/ (ou $ASDF_DATA_DIR)
Volta	~/.volta/tools/image/node/ (ou $VOLTA_HOME)

Chaque version installée forme un élément, par exemple node v18.20.4 (nvm). Une même version installée par deux gestionnaires apparaît deux fois, et les détails indiquent où elle est installée par ailleurs.

Ce qui est conservé

Une version de Node ne vaut la peine d'être supprimée que si rien ne l'utilise. lu-cleaner vérifie toutes les raisons de la conserver, dans cet ordre :

Raison	Risque	Effet
Un processus en cours l'utilise (ligne de commande, ou binaire node qu'il exécute)	caution	ne peut pas être sélectionnée
C'est le node de votre PATH	caution	avertissement this is the node on your PATH
C'est une version par défaut : l'alias default de nvm, l'alias default de fnm, la configuration globale de mise, ~/.tool-versions (mise et asdf), la version par défaut de Volta	caution	avertissement default version: …
Un projet la fixe dans .nvmrc, .node-version ou .tool-versions	moderate	avertissement pinned by N project file(s): …
Un autre alias pointe vers elle (nvm ou fnm)	moderate	avertissement referenced by …
Des paquets npm globaux ne sont installés que dans cette version	moderate	avertissement global packages installed only here: …
Aucune des raisons ci-dessus, mais c'est la plus récente de ces versions pour son gestionnaire (les keep_latest plus récentes, 1 par défaut)	moderate	non recommandée
Aucune des raisons ci-dessus	moderate	recommandée

Pourquoi autant de rigueur : supprimer la version par défaut ou le node de votre PATH casse tous les nouveaux shells, et supprimer une version fixée casse nvm use dans le projet concerné. Les paquets globaux (npm install -g) vivent dans le dossier de la version et disparaissent avec lui : une version qui contient des CLI introuvables ailleurs est donc signalée même si rien d'autre ne la référence. La version non référencée la plus récente de chaque gestionnaire est aussi tenue à l'écart de la sélection intelligente : une version que vous venez d'installer et que vous activez avec nvm use dans des shells actuellement fermés ne correspond à aucune référence sur le disque, mais c'est probablement celle vers laquelle vous migrez.

L'âge ne compte pas ici : une version non référencée plus ancienne est recommandée même si vous l'avez utilisée la semaine dernière, puisqu'une réinstallation prend quelques secondes. Ajoutez --older-than (par exemple --older-than 90d) pour être plus prudent dans vos scripts. Si lu-cleaner ne peut pas lire la liste des processus (ps), il ne peut pas exclure qu'une version soit en cours d'exécution, et aucune version n'est recommandée.

Comment les versions fixées sont reconnues

Les fichiers qui fixent une version sont lus dans vos racines de projets et de worktrees, sur trois niveaux de profondeur, ainsi que dans ~/.nvmrc et ~/.node-version. Une version fixée conserve la version que le gestionnaire choisirait pour elle :

Valeur fixée	Version conservée
20.19.5	cette version ; si elle n'est pas installée, la 20.x installée la plus récente
20 ou 20.19	la version installée la plus récente qui correspond à ce préfixe
^20.11.0, >=20, ~20.11	la 20.x installée la plus récente (les plages sont réduites à leur version majeure)
lts/iron, lts/jod	la version installée la plus récente de cette ligne LTS (20, 22…)
lts/*	la version LTS (majeure paire) installée la plus récente
node, latest, stable	la version installée la plus récente
system	aucune

Les chaînes d'alias de nvm sont suivies (default → lts/* → lts/jod → v22.12.0) : c'est donc bien la version réellement utilisée par votre shell qui est conservée.

Ce que coûte la suppression d'une version

La note de l'élément donne la commande de réinstallation, comme nvm install 18.20.4, fnm install 18.20.4, mise install node@18.20.4, asdf install nodejs 18.20.4 ou volta install node@18.20.4. Le téléchargement fait environ 50 Mo, mais les paquets npm globaux installés sous cette version sont perdus. Les liens symboliques d'alias de mise qui pointent vers la version (20, lts…) sont supprimés avec elle.

Pour fnm, la date de dernière utilisation (la colonne de l'âge, et la valeur à laquelle --older-than se compare) provient aussi des liens de shell décrits ci-dessous : une version vers laquelle vous basculez souvent ne paraît donc pas ancienne.

Liens de shell de fnm

fnm crée un lien symbolique nommé <pid>_<timestamp> dans un dossier fnm_multishells (par exemple ~/.local/state/fnm_multishells ou ~/Library/Caches/fnm_multishells) chaque fois qu'un shell exécute fnm env, et ne les supprime jamais. Des milliers s'accumulent sur une machine où des outils d'IA ouvrent des shells toute la journée. Ils ne prennent presque pas de place ; le gain porte sur les inodes et sur la taille du dossier, bien plus réduite.

Le <pid> est celui du processus fnm env, qui ne vit que brièvement, et non celui du shell : « ce pid est mort » ne prouve donc rien. Un terminal ouvert, ou une application qui a capturé un environnement de shell (Claude, Cursor, Codex…), pointe toujours vers son lien via le PATH. lu-cleaner ne considère un lien comme périmé que dans l'un de ces cas :

• il a été créé avant le dernier démarrage de la machine, puisque tous les processus ont redémarré depuis ;
• il a plus d'un jour, aucun processus en cours ne le référence (ligne de commande ou environnement), et aucun processus en cours n'a démarré vers le moment de sa création.

Le lien de votre propre shell est toujours conservé. L'élément, fnm stale shell links (N), est safe et recommandé ; seuls les liens symboliques sont supprimés, jamais Node lui-même. Sa taille est une estimation, car les liens symboliques n'ont pas de blocs de données. Il est ignoré quand la liste des processus n'est pas disponible, et au moment du nettoyage, un lien à travers lequel un processus s'exécute encore est refusé avec in use: process … runs a program or library from ….

Restes d'un npm install -g interrompu

Quand un npm install -g est interrompu, ce qui arrive souvent avec les CLI d'IA qui se mettent à jour toutes seules, npm laisse dans le lib/node_modules global un dossier temporaire comme .some-cli-a1B2c3D4, qui pèse parfois plusieurs centaines de Mo. npm ne s'en sert plus jamais.

lu-cleaner les cherche dans chaque version de Node gérée et dans les préfixes npm de niveau utilisateur ($npm_config_prefix, ~/.local, ~/.npm-global, ~/.npm-packages). Les restes de plus de 24 heures qu'aucun processus en cours n'utilise sont safe et recommandés (type npm-global-leftover).

Metro, Jest et autres caches temporaires

Ces caches se trouvent dans votre dossier temporaire utilisateur ($TMPDIR, sous /var/folders/…). Plusieurs d'entre eux grossissent avec chaque worktree git, car ils sont indexés par chemin de projet.

Élément	Emplacement	Type (-k)	Remarques
Cache du bundler Metro	$TMPDIR/metro-cache, metro-bundler-cache*, react-native-packager-cache-*	js-metro-cache	partagé par tous les projets React Native / Expo ; comme avec --reset-cache, le bundle suivant est plus lent
File maps de Metro / Haste	$TMPDIR/metro-file-map-*, haste-map-*	js-metro-file-maps	une par racine de projet : chaque worktree en ajoute une
Cache de Jest	$TMPDIR/jest_*	js-jest-cache	un jeu par chemin de projet (environ 100 Mo par worktree)
Dossiers du module runner de Vitest	dossiers de 21 caractères dans $TMPDIR qui ne contiennent que client/ et ssr/	vitest-tmp	recréés à chaque exécution, jamais supprimés
Dossiers de codegen React Native	$TMPDIR/<lib>XXXXXX/out avec une sortie de codegen	rn-codegen-tmp	créés à chaque pod install ou exécution de Gradle, jamais supprimés
Cache de compilation des modules Node	$TMPDIR/node-compile-cache, v8-compile-cache-*	js-node-compile-cache	cache de code V8 des CLI (npm, CLI d'IA…), un par version de Node
Cache de transformation de tsx	$TMPDIR/tsx-*	js-tsx-cache	reconstruit automatiquement

Tous sont safe. Les dossiers de Vitest et de codegen ont des noms génériques : lu-cleaner vérifie donc leur contenu avant de les proposer, et ignore ceux modifiés au cours des 2 dernières heures, au cas où une exécution serait en cours.

React Native, Expo et EAS

Élément	Emplacement	Type (-k)	Risque
Archives précompilées de React Native (core, deps, Hermes)	~/Library/Caches/ReactNative	js-react-native-prebuilt	safe : le prochain pod install les télécharge de nouveau
Cache DotSlash (React Native DevTools)	~/Library/Caches/dotslash	js-dotslash-cache	safe
Restes de Flipper	~/.flipper	js-flipper-leftovers	safe, toujours recommandés : Flipper a été retiré de React Native 0.74+
Caches de l'Expo CLI	~/.expo/cache, native-modules-cache, schema-cache, versions-cache, template-cache	js-expo-cli-caches	safe
Builds Expo Go pour le simulateur iOS	~/.expo/ios-simulator-app-cache/Expo-Go-*	expo-go-ios	voir ci-dessous
APK Expo Go pour Android	~/.expo/android-apk-cache	js-expo-go-android	safe
Archives d'envoi de l'EAS CLI (de plus d'un jour)	$TMPDIR/eas-cli-nodejs	js-eas-cli-tmp	safe ; une archive récente peut appartenir à un envoi en cours
Cache de l'EAS CLI	~/Library/Caches/eas-cli	js-eas-cli-cache	safe
Dossiers de travail de eas build --local (de plus de 2 heures)	$TMPDIR/eas-build-local-nodejs	js-eas-local-build	safe ; ne nettoyez pas pendant un build local

expo start --ios met en cache un build Expo Go (environ 250 Mo) par version. Les versions d'Expo Go suivent le numéro du SDK (52.0.3 correspond au SDK 52) : lu-cleaner les regroupe donc par SDK. Un build remplacé par un build plus récent du même SDK est safe et recommandé ; le build le plus récent de chaque SDK est moderate et porte un avertissement quand un projet de vos racines utilise ce SDK Expo.

Votre session Expo (~/.expo/state.json) figure sur la liste protégée du garde-fou de sécurité et n'est jamais touchée.

Navigateurs de test

Élément	Emplacement	Type (-k)	Risque
Navigateurs Playwright, un élément par révision	~/Library/Caches/ms-playwright/<browser>-<revision>	playwright-browser	moderate
Profils temporaires, traces et cache de transformation de Playwright (de plus d'un jour)	$TMPDIR/playwright-*, $TMPDIR/playwright_*dev_profile-*	js-playwright-tmp	safe
Chrome, headless shell et Firefox de Puppeteer (le plus récent est conservé, ou les keep_latest plus récents)	~/.cache/puppeteer/…	js-puppeteer-chrome, js-puppeteer-headless-shell, js-puppeteer-firefox	moderate
Versions de l'application Cypress (la plus récente est conservée, ou les keep_latest plus récentes)	~/Library/Caches/Cypress/*	js-cypress-binaries	moderate
Pilotes de Selenium Manager	~/.cache/selenium	js-selenium-drivers	safe

Playwright enregistre dans ms-playwright/.links quelles installations ont besoin de quelles révisions de navigateur. lu-cleaner lit ces liens et le browsers.json de chaque installation : une révision dont aucune installation de Playwright n'a plus besoin est recommandée, et une révision encore nécessaire porte needed by N installed Playwright(s). Quand les liens ne sont pas disponibles, les révisions plus anciennes sont recommandées, et la révision la plus récente de chaque navigateur ne l'est qu'une fois périmée. Un navigateur en cours d'exécution n'est jamais recommandé. $PLAYWRIGHT_BROWSERS_PATH est pris en compte.

Watchman

Watchman continue de surveiller des dossiers après leur suppression, typiquement les worktrees des tâches d'agent terminées. Quand watchman watch-list montre des surveillances sur des dossiers qui n'existent plus, de façon vérifiée, lu-cleaner propose de supprimer ces surveillances et le recommande. Il lance watchman watch-del <root> une fois par surveillance périmée, jamais watch-del-all : les surveillances d'un Metro ou d'un jest --watch en cours d'exécution ne sont pas touchées et continuent donc de voir les modifications de fichiers.

Cela libère de la mémoire et du CPU, pas de l'espace disque. Juste avant l'exécution, lu-cleaner liste de nouveau les surveillances et ignore l'élément si un dossier existe de nouveau ou si une surveillance a déjà disparu. Il interroge Watchman avec --no-spawn : ni un scan ni un nettoyage ne démarrent donc jamais le serveur Watchman.

Autres caches d'outils JS

Le catalogue couvre aussi les en-têtes de node-gyp, les caches de téléchargement de nvm, Volta, asdf et mise, les téléchargements d'Electron et d'electron-builder, le cache d'acquisition de types de TypeScript, Deno, Turborepo, esbuild, les binaires SWC de Next.js, les moteurs Prisma, les backends locaux de Convex et les templates giget. Tous sont safe : l'outil concerné les télécharge ou les reconstruit quand il en a besoin.

Marche à suivre recommandée

1. Arrêtez Metro, les watchers de Jest et les exécutions de tests, pour que leurs caches ne soient pas en cours d'utilisation.

2. Vérifiez que vos racines de projets incluent tous vos dossiers de projets et de worktrees, pour que les versions de Node fixées et les projets Yarn PnP soient trouvés :

   lu-cleaner config show

3. Passez en revue ce qui est présent :

   lu-cleaner scan -c js --all

4. Ouvrez le sélecteur, appuyez sur a pour sélectionner les éléments recommandés (ou choisissez avec space), vérifiez la sélection (en particulier les versions de Node et les stores pnpm), puis appuyez sur d :

   lu-cleaner clean -c js

Depuis un script

# Le plan que la sélection intelligente exécuterait ; rien n'est supprimé
lu-cleaner clean --yes --smart -c js --dry-run

# Uniquement les caches de Metro, Haste et Jest
lu-cleaner clean --yes -k js-metro-cache,js-metro-file-maps,js-jest-cache

# Uniquement les versions de Node non référencées
lu-cleaner clean --yes --smart -k node-version --dry-run

Restreignez toujours clean --yes

Sans --smart, lu-cleaner clean --yes -c js inclut tous les éléments sélectionnables jusqu'au risque moderate qui ne portent aucun avertissement : les stores pnpm entiers, les versions de Node non référencées les plus récentes et toutes les installations npx. Les éléments qui portent un avertissement (versions de Node fixées, versions qui contiennent des paquets globaux introuvables ailleurs, installations npx utilisées par des serveurs MCP en cours d'exécution) sont retenus et listés sous Held back. Utilisez --smart ou -k, et lancez une première fois avec --dry-run. Les versions de Node par défaut ou présentes dans votre PATH, un cache Yarn utilisé par des projets Plug'n'Play, un store pnpm avec un store virtuel global (caution) et les éléments qui portent un avertissement ne sont inclus qu'avec --risk caution.

L'identifiant de fournisseur js sélectionne tous les éléments du scanner des versions de Node (versions de Node, liens fnm, restes de npm -g, npx, pnpm, Yarn Berry, Expo Go, Playwright, dossiers temporaires de Vitest et de codegen, Watchman) ; les types js-* proviennent du catalogue. Les métadonnées des éléments, comme kept_because, globals_only_here, pnp_projects ou used_by, sont disponibles dans lu-cleaner scan --json ; voir Sortie JSON.

Voir aussi

Projets React Nativenode_modules, Pods, builds et .expo dans chaque projet.

Worktrees des agents IAChaque worktree ajoute des caches Metro, Jest et Xcode : supprimez d'abord ceux qui sont terminés.

Niveaux de risque et sélection intelligenteCe que signifient safe, moderate et caution, et ce qui est recommandé.

AutomatisationLancer un nettoyage recommandé à intervalles réguliers.