Jest: Bug : le mode Watch sur Linux provoque une erreur ENOSPC Node.js

Cela signifie qu'il n'y a pas d'espace sur votre disque. Veuillez nettoyer votre disque.

@cpojer je ne sais pas si vous avez lu le problème, mais ;

Espace disque libre : df -h / (11% utilisé)

y a été mentionné - l'espace disque, bien que signalé comme le problème, n'est en fait pas le problème.

Bosse @cpojer

J'ai le même problème et il y a définitivement de l'espace disque libre

Malheureusement, nous n'avons pas de ressources pour déboguer cela sous Linux. Si vous avez le temps et que vous pouviez jeter un coup d'œil et nous aider avec une demande de tirage pour le corriger, ce serait grandement apprécié.

@cpojer Je vais jeter un œil - mais je pense aussi que cela ne se limite pas au système d'exploitation Linux. Quoi qu'il en soit, cela vous dérange-t-il de rouvrir ce problème ?

D'après mes découvertes, ce n'est pas du tout lié à Jest. Sous Linux (ou Mac), nous avons un nombre maximum de veilleurs système que nous pouvons placer au niveau des E/S (d'après ma compréhension). Ainsi, pour les grands projets, il semble que Jest essaie de surveiller de nombreux fichiers.

Pour corriger :

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source : Node.JS Erreur : ENOSPC

Merci pour votre enquête, si vous installez Watchman, cela devrait fonctionner.

Tout récemment passé de Windows 7 à Ubuntu 16.04.2 LTS et Jest fonctionnait très bien sous Windows mais ne fonctionnait pas sous Linux pour les mêmes raisons énumérées ci-dessus. Cela ne semble échouer que si vous ajoutez le drapeau --watch .

Tout d'abord, j'ai suivi les conseils de @cpojer et installé des gardiens conformément à la documentation, puis j'ai réexécuté le jest --watch et j'ai obtenu les erreurs suivantes :

jest --watch

events.js:163
      throw er; // Unhandled 'error' event
      ^

Error: A non-recoverable condition has triggered.  Watchman needs your help!
The triggering condition was at timestamp=1493335106: inotify-add-watch(/home/username/project_name/node_modules/browser-resolve/node_modules/resolve/example) -> The user limit on the total number of inotify watches was reached; increase the fs.inotify.max_user_watches sysctl
All requests will continue to fail with this message until you resolve
the underlying problem.  You will find more information on fixing this at
https://facebook.github.io/watchman/docs/troubleshooting.html#poison-inotify-add-watch

    at ChildProcess.<anonymous> (/home/username/project_name/node_modules/sane/node_modules/fb-watchman/index.js:207:21)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:194:7)
    at maybeClose (internal/child_process.js:899:16)
    at Socket.<anonymous> (internal/child_process.js:342:11)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at Pipe._handle.close [as _onclose] (net.js:510:12)
npm ERR! Test failed.  See above for more details.

C'était utile car cela vous dit quoi faire, alors j'ai ensuite utilisé le correctif de @maraisr et jest travaille maintenant sur Ubuntu :tada: :beers:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Merci d'avoir compris @maraisr @cpojer :+1: Pensez-vous que quelque chose devrait être ajouté au site Jest ?

Merci frère @maraisr

@maraisr savez-vous s'il existe une version sans sudo de cette solution, par hasard ?

@vspedr pas sûr - je peux jeter un œil !

Mais nous touchons aux fichiers système là-bas, donc pour la sécurité, vous avez en quelque sorte besoin d'autorisations élevées. Si vous pouvez vous faire un sudoer, je pense que vous pouvez exécuter ces commandes sans sudo.

Mais oui, je vais jeter un œil et voir ce que je peux trouver.

Peut-être que j'ai raté quelque chose... mais pourquoi jest a-t-il besoin de regarder quoi que ce soit dans mon répertoire node_modules ?
Comment puis-je le configurer pour qu'il saute node_modules ?

https://facebook.github.io/jest/docs/en/configuration.html#watchpathignorepatterns -array-string pourrait aider ?

@SimenB , comme je vois que watchPathIgnorePatterns ignore les fichiers uniquement après que la montre elle-même est opérationnelle, c'est pourquoi le démarrage de la montre peut prendre beaucoup de temps et peut parfois lancer ENOSPC

Ah ok. Un PR respectant watchPathIgnorePatterns lors de la configuration des observateurs serait bien :)

@SimenB pouvez-vous s'il vous plaît m'indiquer l'endroit dans le code source où il commence directement à regarder ? j'ai du mal a trouver cet endroit

Découvrez que l'observateur utilise HasteMap comme source de tous les fichiers qui doivent être surveillés, et la question en ce moment en cours de construction de HasteMap.
HasteMap respecte l'option modulePathIgnorePatterns, mais il n'est pas logique d'utiliser cette option en fonction de la description de la documentation :

Un tableau de chaînes de modèles d'expressions rationnelles qui correspondent à tous les chemins de module avant que ces chemins ne soient considérés comme « visibles » pour le chargeur de module. Si le chemin d'un module donné correspond à l'un des modèles, il ne pourra pas être requis() dans l'environnement de test.

ai-je raison?

@maraisr

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

cette solution ne fonctionne pas sur mon mac os 10.13.4 elle renvoie l'erreur ci-dessous

sysctl: illegal option -- p usage: sysctl [-bdehiNnoqx] name[=value] ... sysctl [-bdehNnoqx] -a sysctl: illegal option -- p usage: sysctl [-bdehiNnoqx] name[=value] ... sysctl [-bdehNnoqx] -a

Je ne vois pas pourquoi ce bug est "Fermé". Forcer l'utilisateur à sudo pour une tâche banale est certainement un bogue.

C'est un bogue unique à Jest : moka, guard, etc. tous surveillent des _sous-répertoires_ spécifiques, pas . , pour éviter ce problème. (La liste des sous-répertoires peut être facultative.)

Dans Jest 21, je n'ai jamais eu ce problème. vscode est en concurrence avec Jest pour regarder les fichiers. quand je ferme vscode, jest commence à fonctionner correctement.

J'avais ce problème lorsque j'ai ouvert deux instances de VSCode.

Veuillez rouvrir ou ajouter le correctif au dépannage pour le test.

Cela m'a pris tellement de temps à trouver et enfin à réparer. J'ai commencé à faire des solutions de contournement encore et encore. Merci @samit4me !

J'ai eu cela avec 2 instances de VSCode ouvertes, ce qui est tout à fait logique.

Pour éviter ce bug, utilisez simplement sublime/atom/gedit. Ou vous pouvez fermer VSCode pendant la construction/le débogage.

lsof | wc -l
peut faire la lumière sur la source du problème.
N'importe quel programme, qu'il s'agisse d'un navigateur ou construit avec un moteur Web à l'intérieur (c'est-à-dire du code VS), augmentant considérablement le nombre de descripteurs de fichiers ouverts (environ 30 000 et plus par programme).
Je ne vois pas de solution de contournement fiable, car. la technologie web devient omniprésente

Bravo pour le point dans la bonne direction à ce sujet. J'ai eu le même problème avec l'échec de la montre, mais dans ce cas, une seule instance de VSCode en cours d'exécution. En fermant cela, puis en exécutant mon projet et en le réactivant, l'a résolu.

OMI, c'est inacceptable qu'il y ait une surveillance sur node_modules

Il s'agit principalement de fichiers fonctionnels (et de nombreux fichiers supprimés) du moteur Web, mais pas de node_modules, qui bloquent les nœuds libres pour l'observateur.

J'ai eu cette erreur lorsque je mets à jour les dépendances du projet. Pour résoudre, je viens de supprimer le et d'installer le node_modules

Merci beaucoup

@maraisr Super, echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p fonctionné pour moi sur Ubuntu 18.04.1 LTS

@maraisr Merci pour votre correction fonctionne parfaitement sur ubuntu 18 comme le dit @xameeramir

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p corrigé pour moi aussi :+1:

Sachez que /etc/sysctl.conf est généralement écrasé lors de la mise à niveau (par exemple d'Ubuntu 16 à 18 LTS) et supprimera la limite supérieure. J'ai été prévenu à ce sujet, mais il est facile de passer à côté d'une mer d'autres avertissements similaires. Même si j'ai _vu_ la différence max_user_watches , j'ai quand même été lancé pour une boucle ce matin lorsque j'ai rencontré l'erreur pour la première fois, car il n'est pas évident que ces choses soient connectées. Cependant, une fois que j'ai atterri sur cette page de problème, il était clair ce que je devais corriger.

Hourra pour avoir résolu un problème que j'avais résolu il y a deux ans :rire:

Chose amusante à propos de fs.inotify.max_user_watches=524288
Dans mon cas, il semble que le projet soit suffisamment grand pour que 524288 ne soit pas un nombre assez grand. Alors... eh bien, fs.inotify.max_user_watches=2048000 aidé.
Cela pourrait également être lié à la question d'ouvrir beaucoup de choses dans vs code sur le côté.

Obtenir ceci sur Ubuntu 18.10 lorsque j'exécute "npm start" sur mon create-react-app vierge intact
TRAVAILLÉ!!!
SOLUTION
echo fs.inotify.max_user_watches=2048000 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Pour ce que ça vaut : Peut-être que c'est lié à l'environnement (module X vs module Y).

J'ai 2 applications ReactNative qui ont 2 configurations différentes. Principalement parce que l'un d'eux utilise React-Native-Camera qui n'est pas encore prêt pour les dernières versions de RN (c'est-à-dire : la dernière Gradle et un environnement similaire). L'autre est une démo pour tester la dernière version et l'environnement RN.

L'application utilisant React-Native-Camera se compile parfaitement (--variant=release) sur Linux . L'autre a eu l'erreur ENOSPC . Le correctif "fs.inotify.max_user_watches" a fonctionné. J'étais comme "hein?". Comme décrit par d'autres, j'ai des tonnes de gigaoctets sur le NAS...

Voici le "package.json" des deux applications.

Peut-être que vous trouverez quelque chose d'utile.
Application 1 (Appareil photo) :

{
  "name": "********************",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node node_modules/react-native/local-cli/cli.js start",
    "test": "jest"
  },
  "dependencies": {
    "i18n-js": "^3.0.11",
    "react": "16.4.1",
    "react-native": "0.56.0",
    "react-native-camera": "^1.2.0",
    "react-native-languages": "^3.0.1",
    "react-navigation": "^2.16.0"
  },
  "devDependencies": {
    "babel-jest": "23.4.2",
    "babel-preset-react-native": "5.0.2",
    "jest": "23.5.0",
    "react-test-renderer": "16.4.1"
  },
  "jest": {
    "preset": "react-native"
  }
}

Application 2 (test démo) :

{
  "name": "DemoReactNative",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node node_modules/react-native/local-cli/cli.js start",
    "test": "jest"
  },
  "dependencies": {
    "i18n-js": "^3.0.11",
    "react": "16.6.0-alpha.8af6728",
    "react-native": "0.57.3",
    "react-native-languages": "^3.0.1",
    "react-navigation": "^2.18.0"
  },
  "devDependencies": {
    "babel-jest": "23.6.0",
    "jest": "23.6.0",
    "metro-react-native-babel-preset": "0.48.1",
    "react-test-renderer": "16.6.0-alpha.8af6728"
  },
  "jest": {
    "preset": "react-native"
  }
}

maraisr,
merci fonctionne !!!

juste courir comme sudo a fonctionné pour moi

@ 4E71-NOP J'ai vu la même chose. Une fois que nous avons mis à jour de RN 0.51 à 0.57, nous avons commencé à rencontrer ce problème. L'augmentation de la limite de inotify aidé

Je cours avec sudo ... et ça marche pour moi

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Cela m'a aidé pour UBUNTU 18.10

Merci beaucoup. Mais tout comme @adamhooper mentionné précédemment, Forcing the user to sudo for a mundane task is certainly a bug.

Des idées pour un utilisateur régulier ?

echo fs.inotify.max_user_watches=524288 |

D'après mes découvertes, ce n'est pas du tout lié à Jest. Sous Linux (ou Mac), nous avons un nombre maximum de veilleurs système que nous pouvons placer au niveau des E/S (d'après ma compréhension). Ainsi, pour les grands projets, il semble que Jest essaie de surveiller de nombreux fichiers.

Pour corriger :

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source : Node.JS Erreur : ENOSPC

Parfaitement résolu mon problème, merci beaucoup!

Je l'ai corrigé en excluant node_modules avec le paramètre modulePathIgnorePatterns .

Ajoutez ceci à votre package.json :

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

A fonctionné comme un charme. Merci @maraisr !

[hayesmaker64<strong i="5">@gohan</strong> hype-layer]$ npm test

> [email protected] test /home/hayesmaker64/Workspace/twitch/hype-layer
> react-scripts test

internal/fs/watchers.js:173
    throw error;
    ^

Error: ENOSPC: System limit for number of file watchers reached, watch '/home/hayesmaker64/Workspace/twitch/hype-layer/node_modules/get-stream'
    at FSWatcher.start (internal/fs/watchers.js:165:26)
    at Object.watch (fs.js:1254:11)
    at NodeWatcher.watchdir (/home/hayesmaker64/Workspace/twitch/hype-layer/node_modules/sane/src/node_watcher.js:175:20)
    at Walker.<anonymous> (/home/hayesmaker64/Workspace/twitch/hype-layer/node_modules/sane/src/common.js:116:12)
    at Walker.emit (events.js:182:13)
    at /home/hayesmaker64/Workspace/twitch/hype-layer/node_modules/walker/lib/walker.js:69:16
    at go$readdir$cb (/home/hayesmaker64/Workspace/twitch/hype-layer/node_modules/graceful-fs/graceful-fs.js:162:14)
    at FSReqWrap.oncomplete (fs.js:141:20)
npm ERR! Test failed.  See above for more details.
[hayesmaker64<strong i="6">@gohan</strong> hype-layer]$ ^C
[hayesmaker64<strong i="7">@gohan</strong> hype-layer]$ ^C
[hayesmaker64<strong i="8">@gohan</strong> hype-layer]$ npm test

> [email protected] test /home/hayesmaker64/Workspace/twitch/hype-layer
> react-scripts test


Out of the box, Create React App only supports overriding these Jest options:

  • collectCoverageFrom
  • coverageReporters
  • coverageThreshold
  • globalSetup
  • globalTeardown
  • resetMocks
  • resetModules
  • snapshotSerializers
  • watchPathIgnorePatterns.

These options in your package.json Jest configuration are not currently supported by Create React App:

  • modulePathIgnorePatterns

If you wish to override other Jest options, you need to eject from the default setup. You can do so by running npm run eject but remember that this is a one-way operation. You may also file an issue with Create React App to discuss supporting more options out of the box.

Pour les futurs visiteurs, la solution de @pomber est objectivement bien meilleure que d'augmenter la limite de surveillance :

Ajoutez ceci à votre package.json :

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

D'après mes découvertes, ce n'est pas du tout lié à Jest. Sous Linux (ou Mac), nous avons un nombre maximum de veilleurs système que nous pouvons placer au niveau des E/S (d'après ma compréhension). Ainsi, pour les grands projets, il semble que Jest essaie de surveiller de nombreux fichiers.

Pour corriger :

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source : Node.JS Erreur : ENOSPC

Cela a résolu un problème que je rencontrais avec Vue lors de l'exécution de npm run serve Merci pour la suggestion @maraisr

@pomber Merci, cela résout mon problème sur Fedora sans augmenter la limite du système.

Merci @maraisr , ça résout mon problème :)

Merci beaucoup! @maraisr

Votre solution a fonctionné pour moi, @maraisr !
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Merci!

C'était mon erreur pour ceux que ça intéresse :
Les journaux de votre projet apparaîtront ci-dessous. Appuyez sur Ctrl+C pour quitter.
(nœud : 19425) UnhandledPromiseRejectionWarning : Erreur : ENOSPC : limite du système pour le nombre d'observateurs de fichiers atteint, regardez '/home/claire/Documents/my-app-name'
à FSWatcher.start (internal/fs/watchers.js:165:26)
à Object.watch (fs.js:1274:11)
à NodeWatcher.watchdir (/home/claire/Documents/my-app-name/node_modules/sane/src/node_watcher.js:175:20)
au nouveau NodeWatcher (/home/claire/Documents/my-app-name/node_modules/sane/src/node_watcher.js:45:8)
à createWatcher (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:780:23)
sur Array.map ()
à HasteMap._watch (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:936:44)
à _buildPromise._buildFileMap.then.then.hasteMap (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:355:23)
à processTicksAndRejections (interne/process/next_tick.js:81:5)
(nœud : 19425) UnhandledPromiseRejectionWarning : rejet de promesse non géré. Cette erreur provenait soit du lancement d'une fonction asynchrone sans bloc catch, soit du rejet d'une promesse qui n'a pas été gérée avec .catch(). (identifiant de rejet : 1)
(noeud:19425) [DEP0018] DeprecationWarning : les rejets de promesses non gérés sont obsolètes. À l'avenir, les refus de promesses qui ne sont pas traités mettront fin au processus Node.js avec un code de sortie différent de zéro.
ENOSPC : limite du système pour le nombre d'observateurs de fichiers atteint, regardez '/home/claire/Documents/my-app-name'
ENOSPC : limite du système pour le nombre d'observateurs de fichiers atteint, regardez '/home/claire/Documents/my-app-name'

Je l'ai corrigé en excluant node_modules avec le paramètre modulePathIgnorePatterns .

Ajoutez ceci à votre package.json :

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

après cela, supprimez simplement le dossier node_modules et exécutez à nouveau npm install .

"modulePathIgnorePatterns": [
      "node_modules"
    ]

c'est la vraie réponse

Si vous rencontrez régulièrement ce problème et que vous ne pouvez pas ignorer node_modules , l'installation de Watchman vous aidera :
https://facebook.github.io/watchman/

Il existe des optimisations spécifiques à Watchman dans Jest, ce qui améliorera également considérablement votre temps de démarrage pour les grands projets.

À l'avenir, je chercherai à ne pas regarder automatiquement node_modules car cela provoquerait ce type d'erreur (par exemple: pas de Watchman et pas sur Darwin donc impossible d'utiliser fsevents ).

Oh salut @scotthovestadt ! J'espère que tu vas bien!

Pour les futurs visiteurs, la solution de @pomber est objectivement bien meilleure que d'augmenter la limite de surveillance :

Ajoutez ceci à votre package.json :

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

Cela devrait être la première réponse. Les gens - s'il vous plaît, bousculez ça. Pourquoi diriez-vous simplement « oh, à court de mémoire/ressources - donnez-lui plus de mémoire/ressources » sans examiner la cause ?

Malheureusement, nous n'avons pas de ressources pour déboguer cela sous Linux. Si vous avez le temps et que vous pouviez jeter un coup d'œil et nous aider avec une demande de tirage pour le corriger, ce serait grandement apprécié.

Linux est la norme de facto pour tous les développeurs professionnels, vous souciez-vous vraiment des utilisateurs de Windows et Mac ? C'est la honte

@maraisr merci. J'ai résolu le problème. :Danseur:

Pour les futurs visiteurs, la solution de @pomber est objectivement bien meilleure que d'augmenter la limite de surveillance :

Ajoutez ceci à votre package.json :

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

Cela devrait être la première réponse. Les gens - s'il vous plaît, bousculez ça. Pourquoi diriez-vous simplement « oh, à court de mémoire/ressources - donnez-lui plus de mémoire/ressources » sans examiner la cause ?

Juste une note pour l'enregistrement : le correctif actuel n'a pas fonctionné jusqu'au #7585 qui a corrigé le #7544 .

il y a peut-être des problèmes d'autorisation, essayez Sudo npm start

Cette commande augmentera le nombre d'observateurs autorisés :
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
La source

D'après mes découvertes, ce n'est pas du tout lié à Jest. Sous Linux (ou Mac), nous avons un nombre maximum de veilleurs système que nous pouvons placer au niveau des E/S (d'après ma compréhension). Ainsi, pour les grands projets, il semble que Jest essaie de surveiller de nombreux fichiers.

Pour corriger :

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source : Node.JS Erreur : ENOSPC

@maraisr Merci, votre solution a parfaitement fonctionné sur Ubuntu 18.04

D'après mes découvertes, ce n'est pas du tout lié à Jest. Sous Linux (ou Mac), nous avons un nombre maximum de veilleurs système que nous pouvons placer au niveau des E/S (d'après ma compréhension). Ainsi, pour les grands projets, il semble que Jest essaie de surveiller de nombreux fichiers.

Pour corriger :

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source : Node.JS Erreur : ENOSPC

Merci, cela a résolu mon problème.

Futurs visiteurs et @sunnykeshri @JimmyBastos @BrotherDonkey @CodeMonkeyG , pour ma santé mentale, veuillez arrêter de propager le correctif de la limite de surveillance.

Pour les futurs visiteurs, la solution de @pomber est objectivement bien meilleure que d'augmenter la limite de surveillance :

Ajoutez ceci à votre package.json :

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

Cela devrait être la première réponse. Les gens - s'il vous plaît, bousculez ça. Pourquoi diriez-vous simplement « oh, à court de mémoire/ressources - donnez-lui plus de mémoire/ressources » sans examiner la cause ?

Futurs visiteurs et @sunnykeshri @JimmyBastos @BrotherDonkey @CodeMonkeyG , pour ma santé mentale, veuillez arrêter de propager le correctif de la limite de surveillance.

Pour les futurs visiteurs, la solution de @pomber est objectivement bien meilleure que d'augmenter la limite de surveillance :

Ajoutez ceci à votre package.json :

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

Cela devrait être la première réponse. Les gens - s'il vous plaît, bousculez ça. Pourquoi diriez-vous simplement « oh, à court de mémoire/ressources - donnez-lui plus de mémoire/ressources » sans examiner la cause ?

Create React App limite les clés pouvant être utilisées dans la configuration du package jest - quelqu'un a-t-il trouvé un moyen de résoudre ce problème dans une application CRA ?

D'après mes découvertes, ce n'est pas du tout lié à Jest. Sous Linux (ou Mac), nous avons un nombre maximum de veilleurs système que nous pouvons placer au niveau des E/S (d'après ma compréhension). Ainsi, pour les grands projets, il semble que Jest essaie de surveiller de nombreux fichiers.

Pour corriger :

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source : Node.JS Erreur : ENOSPC

Merci resovel o problema já tava procurando a horas o que era esse rro

D'après mes découvertes, ce n'est pas du tout lié à Jest. Sous Linux (ou Mac), nous avons un nombre maximum de veilleurs système que nous pouvons placer au niveau des E/S (d'après ma compréhension). Ainsi, pour les grands projets, il semble que Jest essaie de surveiller de nombreux fichiers.

Pour corriger :

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source : Node.JS Erreur : ENOSPC

Juste une note d'amélioration, vous feriez peut-être mieux de demander aux utilisateurs de vérifier que l'indicateur/la valeur n'existe pas déjà afin qu'ils n'en obtiennent pas des instances en double. Cela ou utilisez une sorte d'outil pour cela.

D'après mes découvertes, ce n'est pas du tout lié à Jest. Sous Linux (ou Mac), nous avons un nombre maximum de veilleurs système que nous pouvons placer au niveau des E/S (d'après ma compréhension). Ainsi, pour les grands projets, il semble que Jest essaie de surveiller de nombreux fichiers.

Pour corriger :

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source : Node.JS Erreur : ENOSPC

Merci pour votre meilleure réponse.

D'après mes découvertes, ce n'est pas du tout lié à Jest. Sous Linux (ou Mac), nous avons un nombre maximum de veilleurs système que nous pouvons placer au niveau des E/S (d'après ma compréhension). Ainsi, pour les grands projets, il semble que Jest essaie de surveiller de nombreux fichiers.

Pour corriger :

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Source : Node.JS Erreur : ENOSPC

merci pour ta réponse
c'est du travail pour moi

Merci @maraisr

Étant donné que les derniers commentaires ont suggéré la solution de contournement précédente et que le correctif ultérieur commence à être enterré, je pense qu'il est nécessaire de réitérer pour les futurs lecteurs (et @pradeepsrawat029 @karsa87 @igorgoiis ) que vous devriez d'abord essayer le correctif ultérieur si applicable, ce qui n'était pas possible à l'origine à cause d'un bogue :

Pour les futurs visiteurs, la solution de @pomber est objectivement bien meilleure que d'augmenter la limite de surveillance :

Ajoutez ceci à votre package.json :

  "jest": {
    "modulePathIgnorePatterns": [
      "node_modules"
    ]
  }

Cela devrait être la première réponse. Les gens - s'il vous plaît, bousculez ça. Pourquoi diriez-vous simplement « oh, à court de mémoire/ressources - donnez-lui plus de mémoire/ressources » sans examiner la cause ?

J'ai pu résoudre ce problème avec sudo react-native start