Jest: Bug: Watch-Modus unter Linux verursacht einen ENOSPC Node.js-Fehler

Das bedeutet, dass auf Ihrem Laufwerk kein Platz mehr ist. Bitte bereinigen Sie Ihre Festplatte.

@cpojer nicht sicher, ob Sie das Problem gelesen haben, aber;

Freier Speicherplatz auf der Festplatte: df -h / (11% verwendet)

wurde dort erwähnt - Festplattenspeicher, obwohl als Problem gemeldet, ist eigentlich nicht das Problem.

Bump @cpojer

Ich habe das gleiche Problem und es ist definitiv freier Speicherplatz vorhanden

Leider haben wir keine Ressourcen, um dies unter Linux zu debuggen. Wenn Sie Zeit haben und einen Blick darauf werfen und uns mit einem Pull-Request helfen könnten, das Problem zu beheben, wäre das sehr dankbar.

@cpojer Ich

Nach meinen Erkenntnissen hat es überhaupt nichts mit Jest zu tun. Unter Linux (oder Mac) haben wir eine maximale Anzahl von Systembeobachtern, die wir auf IO-Ebene platzieren können (nach meinem Verständnis). Bei großen Projekten scheint Jest also zu versuchen, einfach viel zu viele Dateien zu überwachen.

Reparieren:

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

Quelle: Node.JS Fehler: ENOSPC

Vielen Dank für Ihre Untersuchung. Wenn Sie Watchman installieren, sollte es funktionieren.

Erst vor kurzem von Windows 7 auf Ubuntu 16.04.2 LTS gewechselt und Jest funktionierte unter Windows hervorragend, konnte aber aus den oben genannten Gründen nicht unter Linux ausgeführt werden. Es scheint nur zu scheitern, wenn Sie das Flag --watch hinzufügen.

Zuerst habe ich den Rat von @cpojer befolgt und Watchmen gemäß den Dokumenten installiert und das jest --watch erneut ausgeführt und ich habe die folgenden Fehler erhalten:

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.

Dies war nützlich, da es Ihnen sagt, was zu tun ist, also habe ich dann den Fix von @maraisr verwendet und jest arbeitet jetzt an Ubuntu :tada: :beers:

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

Danke, dass du das herausgefunden hast @maraisr @cpojer :+1: Denkst du, dass der Jest-Website etwas hinzugefügt werden sollte?

Danke Bruder @maraisr

@maraisr weißt du, ob es zufällig eine sudo-

@vspedr nicht sicher - kann ich mir anschauen!

Aber wir berühren dort Systemdateien, daher benötigen Sie aus Sicherheitsgründen erhöhte Berechtigungen. Wenn Sie sich selbst zu einem Sudoer machen können, können Sie diese Befehle meiner Meinung nach ohne Sudo ausführen.

Aber ja - ich schaue mal nach, was mir einfällt.

Vielleicht übersehe ich etwas... aber warum muss ich mir etwas in meinem node_modules Verzeichnis ansehen?
Wie kann ich es so konfigurieren, dass node_modules übersprungen wird?

https://facebook.github.io/jest/docs/en/configuration.html#watchpathignorepatterns -array-string könnte helfen?

@SimenB , wie ich sehe, überspringt watchPathIgnorePatterns Dateien erst, nachdem die Uhr selbst gestartet und ausgeführt wurde. Aus diesem Grund kann der Start der Uhr lange dauern und manchmal ENOSPC auslösen

Ach, okay. Eine PR, die watchPathIgnorePatterns respektiert, wenn man Beobachter einrichtet, wäre schön :)

@SimenB kannst du mich bitte auf die Stelle im Quellcode hinweisen, wo es direkt anfängt zu schauen? Es fällt mir schwer, diesen Ort zu finden

Finden Sie heraus, dass der Watcher HasteMap als Quelle für alle Dateien verwendet, die überwacht werden sollten, und die Frage, die sich gerade beim Erstellen von HasteMap befindet.
HasteMap respektiert die modulePathIgnorePatterns-Option, aber es ist nicht logisch, diese Option basierend auf der Beschreibung aus den Dokumenten zu verwenden:

Ein Array von Regexp-Musterzeichenfolgen, die mit allen Modulpfaden abgeglichen werden, bevor diese Pfade für den Modullader als "sichtbar" betrachtet werden. Wenn der Pfad eines bestimmten Moduls mit einem der Muster übereinstimmt, ist es in der Testumgebung nicht require()-fähig.

habe ich recht?

@maraisr

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

diese lösung funktioniert nicht auf meinem mac os 10.13.4 sie gibt den folgenden fehler zurück

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

Ich verstehe nicht, warum dieser Fehler "geschlossen" ist. Den Benutzer für eine banale Aufgabe zu sudo zu zwingen, ist sicherlich ein Fehler.

Es ist ein einziger Fehler bei Jest: Mokka, Wächter usw. beobachten alle _Unterverzeichnisse_, nicht . , um dieses Problem zu vermeiden. (Die Liste der Unterverzeichnisse kann optional sein.)

In Scherz 21 hatte ich dieses Problem nie. vscode konkurriert mit Scherz um das Ansehen der Dateien. Wenn ich vscode schließe, funktioniert jest richtig.

Ich bekam dieses Problem, als ich zwei VSCode-Instanzen geöffnet hatte.

Bitte öffnen Sie die Fehlerbehebung erneut oder fügen Sie sie zum Testen der Fehlerbehebung hinzu.

Ich habe SO lange gebraucht, um es zu finden und endlich zu beheben. Ich habe immer wieder angefangen, Workarounds zu machen. Danke @samit4me !

Ich hatte dies mit 2 Instanzen von VSCode geöffnet, was durchaus Sinn macht.

Um diesem Fehler zu entkommen, verwenden Sie einfach sublime/atom/gedit. Oder Sie können VSCode während des Erstellens/Debuggens schließen.

lsof | wc -l
kann Aufschluss über die Problemquelle geben.
Jedes Programm, ob es ein Browser ist oder mit einer Web-Engine (zB VS-Code) erstellt wurde, erhöht die Anzahl der geöffneten Dateideskriptoren drastisch (etwa 30 000 und mehr pro Programm).
Ich sehe keinen zuverlässigen Workaround, weil. Webtechnologie wird allgegenwärtig

Prost für den Punkt in die richtige Richtung. Ich hatte das gleiche Problem mit einer fehlgeschlagenen Uhr, aber in diesem Fall wurde nur eine Instanz von VSCode ausgeführt. Das Schließen, dann das Ausführen meines Projekts und das erneute Öffnen haben es gelöst.

IMO, es ist inakzeptabel, dass es eine Uhr auf node_modules

Es sind hauptsächlich funktionierende (und eine Menge gelöschter) Dateien von der Web-Engine, aber nicht von node_modules, die freie Knoten für Watcher blockieren.

Ich habe diesen Fehler erhalten, wenn ich die Projektabhängigkeiten aktualisiere. Um das zu lösen, habe ich gerade das node_modules entfernt und installiert

Danke sehr

@maraisr Toll, echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p hat bei mir unter Ubuntu 18.04.1 LTS funktioniert

@maraisr Vielen Dank für @xameeramir sagt

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p es auch für mich behoben :+1:

Beachten Sie, dass /etc/sysctl.conf normalerweise beim Upgrade (zB von Ubuntu 16 auf 18 LTS) überschrieben wird und die obere Grenze entfernt. Ich wurde davor gewarnt, aber es ist leicht, in einem Meer von anderen ähnlichen Warnungen zu übersehen. Obwohl ich den max_user_watches Diff _gesehen_ habe, war ich heute Morgen immer noch in einer Schleife, als ich zum ersten Mal auf den Fehler gestoßen bin, da es nicht offensichtlich ist, dass diese Dinge miteinander verbunden sind. Als ich jedoch auf dieser Problemseite landete, war klar, was ich beheben musste.

Hurra für die Lösung eines Problems, das ich vor zwei Jahren behoben hatte :lacht:

Lustige Sache mit fs.inotify.max_user_watches=524288
In meinem Fall scheint das Projekt groß genug zu sein, dass 524288 nicht groß genug ist. Also... nun, fs.inotify.max_user_watches=2048000 geholfen.
Könnte auch damit zusammenhängen, dass man nebenbei eine Menge Sachen im vs-Code öffnen muss.

Bekomme dies auf Ubuntu 18.10, wenn ich "npm start" auf meiner unberührten, jungfräulichen Create-React-App ausführe
HAT FUNKTIONIERT!!!
LÖSUNG
echo fs.inotify.max_user_watches=2048000 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Was es wert ist: Vielleicht hängt es mit der Umgebung zusammen (Modul X vs. Modul Y).

Ich habe 2 ReactNative-Anwendungen, die 2 verschiedene Konfigurationen haben. Vor allem, weil einer von ihnen eine React-Native-Camera verwendet, die noch nicht für die neuesten RN-Versionen (dh: neueste Gradle und solche Umgebungen) bereit ist. Das andere ist eine Demo zum Testen der neuesten RN-Version und -Umgebung.

Die Anwendung mit React-Native-Camera kompiliert einwandfrei (--variant=release) unter Linux . Der andere bekam den ENOSPC- Fehler. Der Fix "fs.inotify.max_user_watches" hat funktioniert. Ich war wie "hä?". Wie von anderen beschrieben habe ich tonnenweise Gigabyte auf dem NAS...

Hier sind die "package.json" beider Apps.

Vielleicht findest du etwas Nützliches.
App 1 (Kamera):

{
  "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"
  }
}

App 2 (Testdemo):

{
  "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,
danke funktioniert!!!

einfach so laufen, wie sudo bei mir funktioniert hat

@ 4E71-NOP Ich habe dasselbe gesehen. Nachdem wir von RN 0.51 auf 0.57 aktualisiert hatten, stießen wir auf dieses Problem. Die Erhöhung des inotify Limits hat geholfen

ich laufe mit sudo ... und es funktioniert bei mir

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Das hat mir bei UBUNTU 18.10 geholfen

Vielen Dank. Aber genau wie @adamhooper bereits erwähnt hat, Forcing the user to sudo for a mundane task is certainly a bug.

Irgendwelche Ideen für regelmäßige Benutzer?

echo fs.inotify.max_user_watches=524288 |

Nach meinen Erkenntnissen hat es überhaupt nichts mit Jest zu tun. Unter Linux (oder Mac) haben wir eine maximale Anzahl von Systembeobachtern, die wir auf IO-Ebene platzieren können (nach meinem Verständnis). Bei großen Projekten scheint Jest also zu versuchen, einfach viel zu viele Dateien zu überwachen.

Reparieren:

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

Quelle: Node.JS Fehler: ENOSPC

Mein Problem perfekt gelöst, vielen Dank!

Ich habe es ohne node_modules mit der Einstellung modulePathIgnorePatterns behoben.

Fügen Sie dies zu Ihrer package.json hinzu:

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

Lief wie am Schnürchen. Danke @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.

Für zukünftige Besucher ist die Lösung von @pomber objektiv wesentlich besser, als das Watch-Limit zu erhöhen:

Fügen Sie dies zu Ihrer package.json hinzu:

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

Nach meinen Erkenntnissen hat es überhaupt nichts mit Jest zu tun. Unter Linux (oder Mac) haben wir eine maximale Anzahl von Systembeobachtern, die wir auf IO-Ebene platzieren können (nach meinem Verständnis). Bei großen Projekten scheint Jest also zu versuchen, einfach viel zu viele Dateien zu überwachen.

Reparieren:

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

Quelle: Node.JS Fehler: ENOSPC

Dadurch wurde ein Problem behoben, das ich mit Vue beim Ausführen von npm run serve Vielen Dank für den Vorschlag @maraisr

@pomber Danke, es löst mein Problem auf Fedora, ohne das

Danke @maraisr , es löst mein Problem :)

Vielen Dank! @maraisr

Deine Lösung hat für mich funktioniert, @maraisr!
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Danke!

Dies war mein Fehler für alle, die es interessiert:
Die Protokolle für Ihr Projekt werden unten angezeigt. Drücken Sie zum Beenden Strg+C.
(node:19425) UnhandledPromiseRejectionWarning: Fehler: ENOSPC: Systemlimit für die Anzahl der Dateibeobachter erreicht, Watch '/home/claire/Documents/my-app-name'
bei FSWatcher.start (internal/fs/watchers.js:165:26)
bei Object.watch (fs.js:1274:11)
unter NodeWatcher.watchdir (/home/claire/Documents/my-app-name/node_modules/sane/src/node_watcher.js:175:20)
bei neuem NodeWatcher (/home/claire/Documents/my-app-name/node_modules/sane/src/node_watcher.js:45:8)
bei createWatcher (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:780:23)
bei Array.map ()
bei HasteMap._watch (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:936:44)
unter _buildPromise._buildFileMap.then.then.hasteMap (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:355:23)
bei processTicksAndRejections (internal/process/next_tick.js:81:5)
(node:19425) UnhandledPromiseRejectionWarning: Nicht behandelte Versprechensablehnung. Dieser Fehler entstand entweder durch das Einfügen in eine asynchrone Funktion ohne einen catch-Block oder durch das Zurückweisen eines Promises, das nicht mit .catch() verarbeitet wurde. (Ablehnungs-ID: 1)
(node:19425) [DEP0018] DeprecationWarning: Nicht behandelte Promise-Ablehnungen sind veraltet. Zukünftig wird der Node.js-Prozess bei Ablehnungen von Zusagen, die nicht verarbeitet werden, mit einem Exit-Code ungleich Null beendet.
ENOSPC: Systemlimit für Anzahl der Dateibeobachter erreicht, Watch '/home/claire/Documents/my-app-name'
ENOSPC: Systemlimit für Anzahl der Dateibeobachter erreicht, Watch '/home/claire/Documents/my-app-name'

Ich habe es ohne node_modules mit der Einstellung modulePathIgnorePatterns behoben.

Fügen Sie dies zu Ihrer package.json hinzu:

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

Danach entfernen Sie einfach den Ordner node_modules und führen npm install erneut aus.

"modulePathIgnorePatterns": [
      "node_modules"
    ]

das ist die wahre antwort

Wenn dieses Problem ständig auftritt und node_modules nicht ignorieren kann, hilft die Installation von Watchman:
https://facebook.github.io/watchman/

Es gibt Watchman-spezifische Optimierungen innerhalb von Jest, so dass es auch Ihre Startzeit für große Projekte erheblich verbessert.

In Zukunft werde ich versuchen, node_modules nicht automatisch zu beobachten, wenn dies diese Art von Fehler verursachen würde (zB: kein Watchman und nicht auf Darwin, daher kann fsevents ).

Oh Hey @scotthovestadt! Ich hoffe es geht dir gut!

Für zukünftige Besucher ist die Lösung von @pomber objektiv wesentlich besser, als das Watch-Limit zu erhöhen:

Fügen Sie dies zu Ihrer package.json hinzu:

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

Dies sollte die beste Antwort sein. Leute - bitte stoß das an. Warum würden Sie einfach sagen "oh, kein Speicher/Ressourcen - geben Sie ihm mehr Speicher/Ressourcen", ohne die Ursache zu untersuchen?

Leider haben wir keine Ressourcen, um dies unter Linux zu debuggen. Wenn Sie Zeit haben und einen Blick darauf werfen und uns mit einem Pull-Request helfen könnten, das Problem zu beheben, wäre das sehr dankbar.

Linux ist de-facto-Standard für alle professionellen Entwickler, interessieren Sie sich wirklich mehr für Windows- und Mac-Benutzer? Das ist eine Schande

@maraisr danke. Ich habe das Problem gelöst. :Tänzer:

Für zukünftige Besucher ist die Lösung von @pomber objektiv wesentlich besser, als das Watch-Limit zu erhöhen:

Fügen Sie dies zu Ihrer package.json hinzu:

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

Dies sollte die beste Antwort sein. Leute - bitte stoß das an. Warum würden Sie einfach sagen "oh, kein Speicher/Ressourcen - geben Sie ihm mehr Speicher/Ressourcen", ohne die Ursache zu untersuchen?

Nur eine Anmerkung für das Protokoll: Der gegenwärtige richtige Fix funktionierte nicht bis #7585, der #7544 reparierte.

Möglicherweise gibt es Berechtigungsprobleme, versuchen Sie es mit Sudo npm start

Dieser Befehl erhöht die Anzahl der zulässigen Beobachter:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Quelle

Nach meinen Erkenntnissen hat es überhaupt nichts mit Jest zu tun. Unter Linux (oder Mac) haben wir eine maximale Anzahl von Systembeobachtern, die wir auf IO-Ebene platzieren können (nach meinem Verständnis). Bei großen Projekten scheint Jest also zu versuchen, einfach viel zu viele Dateien zu überwachen.

Reparieren:

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

Quelle: Node.JS Fehler: ENOSPC

@maraisr Danke, deine Lösung hat unter Ubuntu 18.04 perfekt funktioniert

Nach meinen Erkenntnissen hat es überhaupt nichts mit Jest zu tun. Unter Linux (oder Mac) haben wir eine maximale Anzahl von Systembeobachtern, die wir auf IO-Ebene platzieren können (nach meinem Verständnis). Bei großen Projekten scheint Jest also zu versuchen, einfach viel zu viele Dateien zu überwachen.

Reparieren:

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

Quelle: Node.JS Fehler: ENOSPC

Danke, das hat mein Problem gelöst.

Zukünftige Besucher und @sunnykeshri @JimmyBastos @BrotherDonkey @CodeMonkeyG , bitte hören Sie für meine Vernunft auf, die Korrektur des Watch-Limits zu propagieren.

Für zukünftige Besucher ist die Lösung von @pomber objektiv wesentlich besser, als das Watch-Limit zu erhöhen:

Fügen Sie dies zu Ihrer package.json hinzu:

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

Dies sollte die beste Antwort sein. Leute - bitte stoß das an. Warum würden Sie einfach sagen "oh, kein Speicher/Ressourcen - geben Sie ihm mehr Speicher/Ressourcen", ohne die Ursache zu untersuchen?

Zukünftige Besucher und @sunnykeshri @JimmyBastos @BrotherDonkey @CodeMonkeyG , bitte hören Sie für meine Vernunft auf, die Korrektur des Watch-Limits zu propagieren.

Für zukünftige Besucher ist die Lösung von @pomber objektiv wesentlich besser, als das Watch-Limit zu erhöhen:

Fügen Sie dies zu Ihrer package.json hinzu:

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

Dies sollte die beste Antwort sein. Leute - bitte stoß das an. Warum würden Sie einfach sagen "oh, kein Speicher/Ressourcen - geben Sie ihm mehr Speicher/Ressourcen", ohne die Ursache zu untersuchen?

Create React App schränkt die Schlüssel ein, die innerhalb des Pakets jest config verwendet werden können - hat jemand einen Weg gefunden, dies in einer CRA-App zu lösen?

Nach meinen Erkenntnissen hat es überhaupt nichts mit Jest zu tun. Unter Linux (oder Mac) haben wir eine maximale Anzahl von Systembeobachtern, die wir auf IO-Ebene platzieren können (nach meinem Verständnis). Bei großen Projekten scheint Jest also zu versuchen, einfach viel zu viele Dateien zu überwachen.

Reparieren:

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

Quelle: Node.JS Fehler: ENOSPC

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

Nach meinen Erkenntnissen hat es überhaupt nichts mit Jest zu tun. Unter Linux (oder Mac) haben wir eine maximale Anzahl von Systembeobachtern, die wir auf IO-Ebene platzieren können (nach meinem Verständnis). Bei großen Projekten scheint Jest also zu versuchen, einfach viel zu viele Dateien zu überwachen.

Reparieren:

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

Quelle: Node.JS Fehler: ENOSPC

Nur ein Hinweis zur Verbesserung, es ist möglicherweise besser, die Benutzer anzuweisen, zu überprüfen, ob das Flag/der Wert noch nicht vorhanden ist, damit sie keine doppelten Instanzen davon erhalten. Das oder verwenden Sie eine Art Werkzeug dafür.

Nach meinen Erkenntnissen hat es überhaupt nichts mit Jest zu tun. Unter Linux (oder Mac) haben wir eine maximale Anzahl von Systembeobachtern, die wir auf IO-Ebene platzieren können (nach meinem Verständnis). Bei großen Projekten scheint Jest also zu versuchen, einfach viel zu viele Dateien zu überwachen.

Reparieren:

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

Quelle: Node.JS Fehler: ENOSPC

Vielen Dank für Ihre beste Antwort.

Nach meinen Erkenntnissen hat es überhaupt nichts mit Jest zu tun. Unter Linux (oder Mac) haben wir eine maximale Anzahl von Systembeobachtern, die wir auf IO-Ebene platzieren können (nach meinem Verständnis). Bei großen Projekten scheint Jest also zu versuchen, einfach viel zu viele Dateien zu überwachen.

Reparieren:

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

Quelle: Node.JS Fehler: ENOSPC

danke für deine antwort
es ist arbeit für mich

Danke @maraisr

Da in den letzten paar Kommentaren der frühere Workaround vorgeschlagen wurde und der spätere Fix langsam begraben wird, halte ich es für notwendig, zukünftigen Lesern (und @pradeepsrawat029 @karsa87 @igorgoiis ) noch einmal zu sagen, dass Sie zuerst den späteren Fix ausprobieren sollten, wenn anwendbar, was ursprünglich wegen eines Scherzfehlers nicht möglich war:

Für zukünftige Besucher ist die Lösung von @pomber objektiv wesentlich besser, als das Watch-Limit zu erhöhen:

Fügen Sie dies zu Ihrer package.json hinzu:

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

Dies sollte die beste Antwort sein. Leute - bitte stoß das an. Warum würden Sie einfach sagen "oh, kein Speicher/Ressourcen - geben Sie ihm mehr Speicher/Ressourcen", ohne die Ursache zu untersuchen?

Ich konnte dieses Problem mit sudo react-native start beheben