Versiones:
Instalado usando : yarn global add jest
(Con chown
en ~/.config/yarn/global/node_modules/
)
El comando falló: jest -c lib/tools/testing/jest.config.json --no-cache --watch
Si ejecuto
jest -c lib/tools/testing/jest.config.json --no-cache
pruebas funcionan 100% bien.
Mensaje de error:
fs.js:1431
throw error;
^
Error: watch /home/fooBar/dev/blah/lib/tools/testing/node_modules/core-js/modules ENOSPC
at exports._errnoException (util.js:1022:11)
at FSWatcher.start (fs.js:1429:19)
at Object.fs.watch (fs.js:1456:11)
at NodeWatcher.watchdir (/home/fooBar/.config/yarn/global/node_modules/sane/src/node_watcher.js:148:20)
at Walker.<anonymous> (/home/fooBar/.config/yarn/global/node_modules/sane/src/node_watcher.js:361:12)
at emitTwo (events.js:106:13)
at Walker.emit (events.js:191:7)
at /home/fooBar/.config/yarn/global/node_modules/walker/lib/walker.js:69:16
at go$readdir$cb (/home/fooBar/.config/yarn/global/node_modules/graceful-fs/graceful-fs.js:149:14)
at FSReqWrap.oncomplete (fs.js:123:15)
Tmp dir: yarn config set tmp /tmp/
Espacio libre en disco: df -h /
(11% usado)
Configuración de broma: en lib/tools/testing/jest.config.json
{
"clearMocks": true,
"bail": true,
"transform": {
".(ts|tsx)": "<rootDir>/lib/tools/testing/node_modules/ts-jest/preprocessor.js"
},
"testResultsProcessor": "<rootDir>/lib/tools/testing/node_modules/ts-jest/coverageprocessor.js",
"testMatch": [
"**/__tests__/*.(ts|tsx|js)"
],
"moduleFileExtensions": [
"ts",
"tsx",
"js"
],
"moduleDirectories": [
"node_modules",
"<rootDir>/lib/tools/testing/node_modules"
],
"collectCoverage": true,
"coverageDirectory": "./reports/",
"coverageReporters": [
"clover",
"lcov",
"text-summary"
],
"coverageThreshold": {
"global": {
"branches": 50,
"functions": 80,
"lines": 60
}
},
"collectCoverageFrom": [
"{src,lib}/**/*.{ts,js}",
"!lib/{tools}/**/*",
"!**/{node_modules,vendor}/**"
]
}
Esto significa que no hay espacio en su disco. Limpie su disco.
@cpojer no estoy seguro de haber leído el problema, pero;
Espacio libre en disco: df -h / (11% usado)
se mencionó allí: el espacio en disco, aunque se informó como el problema, en realidad no es el problema.
Bump @cpojer
Tengo el mismo problema y definitivamente hay espacio libre en el disco.
Desafortunadamente, no tenemos recursos para depurar esto en Linux. Si tiene tiempo y podría echar un vistazo y ayudarnos con una solicitud de extracción para solucionarlo, sería muy apreciado.
@cpojer Voy a echar un vistazo, pero también creo que no se limita al sistema operativo Linux. Independientemente, ¿le importaría volver a abrir este número?
Según mis hallazgos, no está relacionado con Jest en absoluto. En Linux (o Mac) tenemos un número máximo de observadores del sistema que podemos colocar en un nivel IO (según tengo entendido). Entonces, para proyectos grandes, parece que Jest está tratando de ver muchos archivos.
Arreglar:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Fuente: Node.JS Error: ENOSPC
Gracias por investigar, si instala watchman, debería funcionar.
Recientemente, cambié de Windows 7 a Ubuntu 16.04.2 LTS y Jest funcionó muy bien en Windows, pero no se pudo ejecutar en Linux por las mismas razones mencionadas anteriormente. Solo parece fallar si agrega la bandera --watch
.
En primer lugar, tomé el consejo de @cpojer e instalé vigilantes según los documentos y ejecuté jest --watch
nuevamente y obtuve los siguientes errores:
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.
Esto fue útil ya que te dice qué hacer, entonces usé la solución de @maraisr y jest ahora está funcionando en Ubuntu: tada:: beers:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Gracias por resolver esto @maraisr @cpojer : +1: ¿Crees que se debería agregar algo al sitio web de Jest ?
Gracias Bro @maraisr
@maraisr , ¿sabes si hay una versión sin sudo de esa solución, por casualidad?
@vspedr no estoy seguro, ¡puedo echar un vistazo!
Pero estamos tocando los archivos del sistema allí, por lo que por seguridad necesita permisos elevados. Si puede convertirse en un sudoer, creo que puede ejecutar esos comandos sin sudo.
Pero sí, echaré un vistazo y veré qué se me ocurre.
Puede ser que me esté perdiendo algo ... pero ¿por qué Jest necesita ver algo en mi directorio node_modules
?
¿Cómo puedo configurarlo para que omita node_modules
?
https://facebook.github.io/jest/docs/en/configuration.html#watchpathignorepatterns -array-string podría ayudar?
@SimenB , como veo, watchPathIgnorePatterns omite archivos solo después de que el reloj esté en funcionamiento, es por eso que el inicio del reloj puede llevar mucho tiempo y, a veces, puede arrojar ENOSPC
Ah, vale. Un PR que respete watchPathIgnorePatterns
al configurar observadores sería bueno :)
@SimenB, ¿ podría indicarme el lugar del código fuente donde comienza a mirar directamente? Me cuesta encontrar este lugar
Descubra que el observador está utilizando HasteMap como fuente de todos los archivos que se deben ver, y la pregunta ahora mismo está en proceso de construcción de HasteMap.
HasteMap respeta la opción modulePathIgnorePatterns, pero no es lógico usar esta opción según la descripción de los documentos:
Una matriz de cadenas de patrones de expresiones regulares que se comparan con todas las rutas de los módulos antes de que esas rutas se consideren "visibles" para el cargador de módulos. Si la ruta de un módulo dado coincide con alguno de los patrones, no será require () - capaz en el entorno de prueba.
estoy en lo cierto?
@maraisr
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
esta solución no funciona en mi mac os 10.13.4 devuelve el siguiente error
sysctl: illegal option -- p
usage: sysctl [-bdehiNnoqx] name[=value] ...
sysctl [-bdehNnoqx] -a
sysctl: illegal option -- p
usage: sysctl [-bdehiNnoqx] name[=value] ...
sysctl [-bdehNnoqx] -a
No veo por qué este error está "Cerrado". Obligar al usuario a sudo
para una tarea mundana es ciertamente un error.
Es un error exclusivo de Jest: mocha, guard, etc., todos miran _subdirectorios_ específicos, no .
, para evitar este problema. (La lista de subdirectorios podría ser opcional).
En broma 21 nunca tuve este problema. vscode compite con broma por ver los archivos. cuando cierro vscode, Jest comienza a funcionar correctamente.
Estaba teniendo este problema, cuando tenía dos instancias de VSCode abiertas.
Vuelva a abrir o agregue la solución a la solución de problemas para realizar pruebas.
Esto me tomó TAN tiempo para encontrarlo y finalmente arreglarlo. Empecé a hacer soluciones una y otra vez. ¡Gracias @ samit4me !
Tuve esto con 2 instancias de VSCode abiertas, lo cual tiene mucho sentido.
Para escapar de este error, simplemente use sublime / atom / gedit. O puede cerrar VSCode mientras compila / depura.
lsof | wc -l
puede arrojar luz sobre la fuente del problema.
Cualquier programa, ya sea un navegador o construido con un motor web en su interior (es decir, código VS), aumenta drásticamente el número de descriptores de archivos abiertos (alrededor de 30 000 y más por programa).
No veo una solución alternativa confiable, porque. la tecnología web se vuelve omnipresente
Saludos por el punto en la dirección correcta en esto. Tuve el mismo problema con el reloj fallando, pero en este caso solo se está ejecutando una instancia de VSCode. Cerrar eso, luego ejecutar mi proyecto y reabrirlo, lo resolvió.
En mi opinión, es inaceptable que haya un reloj en node_modules
Se trata principalmente de archivos de trabajo (y un montón de archivos eliminados) del motor web, pero no de node_modules, que bloquean los nodos libres para el observador.
Recibí este error cuando actualizo las dependencias del proyecto. Para resolver, acabo de eliminar e instalar el node_modules
Muchísimas gracias
@maraisr Genial, echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
me funcionó en Ubuntu 18.04.1 LTS
@maraisr Gracias por su corrección funciona perfectamente en ubuntu 18 como dice @xameeramir
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
me lo arregló también: +1:
Tenga en cuenta que /etc/sysctl.conf
generalmente se sobrescribe al actualizar (por ejemplo, de Ubuntu 16 a 18 LTS) y eliminará el límite superior. Me advirtieron sobre esto, pero es fácil pasarlo por alto en un mar de otras advertencias similares. A pesar de que vi el max_user_watches
diff, todavía estaba en un bucle esta mañana cuando encontré el error por primera vez, ya que no es obvio que estas cosas estén conectadas. Sin embargo, una vez que llegué a esta página de problemas, estaba claro lo que necesitaba solucionar.
Hurra por volver a resolver un problema que había solucionado hace dos años: riendo:
Lo curioso de fs.inotify.max_user_watches=524288
En mi caso, parece que el proyecto es lo suficientemente grande como para que 524288
no sea un número lo suficientemente grande. Entonces ... bueno fs.inotify.max_user_watches=2048000
ayudó.
También podría estar relacionado con la cuestión de abrir muchas cosas en el código vs en el lateral.
Obteniendo esto en ubuntu 18.10 cuando ejecuto "npm start" en mi virgen create-react-app sin tocar
¡¡¡TRABAJÓ!!!
SOLUCIÓN
echo fs.inotify.max_user_watches = 2048000 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Por lo que vale: tal vez esté relacionado con el medio ambiente (módulo X vs módulo Y).
Tengo 2 aplicaciones ReactNative que tienen 2 configuraciones diferentes. Principalmente porque uno de ellos usa React-Native-Camera que aún no está listo para las últimas versiones de RN (es decir, la última versión de Gradle y ese entorno). El otro es una demostración para probar la última versión y el entorno de RN.
La aplicación que usa React-Native-Camera se compila sin problemas (--variant = release) en Linux . El otro recibió el error ENOSPC . La corrección "fs.inotify.max_user_watches" funcionó. Yo estaba como "¿eh?". Como lo describieron otros, tengo toneladas de gigabytes en el NAS ...
Aquí están los "package.json" de ambas aplicaciones.
Quizás encuentres algo útil.
Aplicación 1 (cámara):
{
"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"
}
}
Aplicación 2 (demostración de prueba):
{
"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,
gracias funciona !!!
simplemente corriendo como sudo funcionó para mí
@ 4E71-NOP Vi lo mismo. Una vez que actualizamos de RN 0.51 a 0.57, comenzamos a encontrarnos con este problema. Aumentar el límite de inotify
ayudó
Yo corro con sudo ... y me funciona
echo fs.inotify.max_user_watches = 524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Esto me ayudó para UBUNTU 18.10
Muchas gracias. Pero tal como @adamhooper mencionó antes, Forcing the user to sudo for a mundane task is certainly a bug.
¿Alguna idea para el usuario habitual?
echo fs.inotify.max_user_watches = 524288 |
Según mis hallazgos, no está relacionado con Jest en absoluto. En Linux (o Mac) tenemos un número máximo de observadores del sistema que podemos colocar en un nivel IO (según tengo entendido). Entonces, para proyectos grandes, parece que Jest está tratando de ver muchos archivos.
Arreglar:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Fuente: Node.JS Error: ENOSPC
Perfectamente resuelto mi problema, muchas gracias!
Lo arreglé excluyendo node_modules
con la configuración modulePathIgnorePatterns
.
Agregue esto a su package.json:
"jest": {
"modulePathIgnorePatterns": [
"node_modules"
]
}
Trabajado como un encanto. ¡Gracias @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.
Para los visitantes futuros, la solución de @pomber es objetivamente mucho mejor que aumentar el límite de visualización:
Agregue esto a su package.json:
"jest": { "modulePathIgnorePatterns": [ "node_modules" ] }
Según mis hallazgos, no está relacionado con Jest en absoluto. En Linux (o Mac) tenemos un número máximo de observadores del sistema que podemos colocar en un nivel IO (según tengo entendido). Entonces, para proyectos grandes, parece que Jest está tratando de ver muchos archivos.
Arreglar:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Fuente: Node.JS Error: ENOSPC
Esto solucionó un problema que estaba experimentando con Vue cuando ejecutaba npm run serve
Gracias por la sugerencia @maraisr
@pomber Gracias, resolvió mi problema en Fedora sin aumentar ningún límite del sistema.
Gracias @maraisr , resuelve mi problema :)
¡Muchas gracias! @maraisr
¡Tu solución funcionó para mí, @maraisr!
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
¡Gracias!
Este fue mi error para cualquiera que esté interesado:
Los registros de su proyecto aparecerán a continuación. Presione Ctrl + C para salir.
(nodo: 19425) UnhandledPromiseRejectionWarning: Error: ENOSPC: Se alcanzó el límite del sistema para el número de observadores de archivos, ver '/ home / claire / Documents / my-app-name'
en FSWatcher.start (interno / fs / watchers.js: 165: 26)
en Object.watch (fs.js: 1274: 11)
en NodeWatcher.watchdir (/home/claire/Documents/my-app-name/node_modules/sane/src/node_watcher.js:175:20)
en el nuevo NodeWatcher (/home/claire/Documents/my-app-name/node_modules/sane/src/node_watcher.js:45:8)
en createWatcher (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:780:23)
en Array.map (
en HasteMap._watch (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:936:44)
en _buildPromise._buildFileMap.then.then.hasteMap (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:355:23)
en processTicksAndRejections (internal / process / next_tick.js: 81: 5)
(nodo: 19425) UnhandledPromiseRejectionWarning: Rechazo de promesa no manejado. Este error se originó al lanzar una función asíncrona sin un bloque de captura o al rechazar una promesa que no se manejó con .catch (). (id de rechazo: 1)
(nodo: 19425) [DEP0018] DeprecationWarning: Los rechazos de promesa no gestionados están obsoletos. En el futuro, los rechazos de promesas que no se manejan terminarán el proceso de Node.js con un código de salida distinto de cero.
ENOSPC: límite del sistema para la cantidad de observadores de archivos alcanzados, ver '/ home / claire / Documents / my-app-name'
ENOSPC: límite del sistema para la cantidad de observadores de archivos alcanzados, ver '/ home / claire / Documents / my-app-name'
Lo arreglé excluyendo
node_modules
con la configuraciónmodulePathIgnorePatterns
.Agregue esto a su package.json:
"jest": { "modulePathIgnorePatterns": [ "node_modules" ] }
después de eso, simplemente elimine la carpeta node_modules
y ejecute npm install
nuevamente.
"modulePathIgnorePatterns": [ "node_modules" ]
esta es la verdadera respuesta
Si se encuentra con este problema constantemente y no puede ignorar node_modules
, instalar Watchman le ayudará:
https://facebook.github.io/watchman/
Hay optimizaciones específicas de Watchman dentro de Jest, por lo que también mejorará significativamente el tiempo de inicio para proyectos grandes.
En el futuro, buscaré no ver automáticamente node_modules
cuando hacerlo causaría este tipo de error (por ejemplo: no hay Watchman y no en Darwin, por lo que no puedo usar fsevents
).
¡Oh, hola @scotthovestadt! ¡Espero que estes bien!
Para los visitantes futuros, la solución de @pomber es objetivamente mucho mejor que aumentar el límite de visualización:
Agregue esto a su package.json:
"jest": { "modulePathIgnorePatterns": [ "node_modules" ] }
Esta debería ser la mejor respuesta. Gente, por favor golpee esto. ¿Por qué diría simplemente "oh, sin memoria / recursos - dele más memoria / recursos" sin examinar la causa?
Desafortunadamente, no tenemos recursos para depurar esto en Linux. Si tiene tiempo y podría echar un vistazo y ayudarnos con una solicitud de extracción para solucionarlo, sería muy apreciado.
Linux es el estándar de facto para todos los desarrolladores profesionales, ¿realmente te preocupan más los usuarios de Windows y Mac? Eso es vergüenza
@maraisr gracias. Resolví el problema. :bailarín:
Para los visitantes futuros, la solución de @pomber es objetivamente mucho mejor que aumentar el límite de visualización:
Agregue esto a su package.json:
"jest": { "modulePathIgnorePatterns": [ "node_modules" ] }
Esta debería ser la mejor respuesta. Gente, por favor golpee esto. ¿Por qué diría simplemente "oh, sin memoria / recursos - dele más memoria / recursos" sin examinar la causa?
Solo una nota para el registro: la solución actual adecuada no funcionó hasta # 7585 que corrigió # 7544.
puede haber algunos problemas de permisos, intente Sudo npm start
Este comando aumentará la cantidad de observadores permitidos:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Fuente
Según mis hallazgos, no está relacionado con Jest en absoluto. En Linux (o Mac) tenemos un número máximo de observadores del sistema que podemos colocar en un nivel IO (según tengo entendido). Entonces, para proyectos grandes, parece que Jest está tratando de ver muchos archivos.
Arreglar:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Fuente: Node.JS Error: ENOSPC
@maraisr Gracias, su solución funcionó perfectamente en Ubuntu 18.04
Según mis hallazgos, no está relacionado con Jest en absoluto. En Linux (o Mac) tenemos un número máximo de observadores del sistema que podemos colocar en un nivel IO (según tengo entendido). Entonces, para proyectos grandes, parece que Jest está tratando de ver muchos archivos.
Arreglar:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Fuente: Node.JS Error: ENOSPC
Gracias, esto resolvió mi problema.
Futuros visitantes y @sunnykeshri @JimmyBastos @BrotherDonkey @CodeMonkeyG , por mi cordura, dejen de propagar la corrección del límite de reloj.
Para los visitantes futuros, la solución de @pomber es objetivamente mucho mejor que aumentar el límite de visualización:
Agregue esto a su package.json:
"jest": { "modulePathIgnorePatterns": [ "node_modules" ] }
Esta debería ser la mejor respuesta. Gente, por favor golpee esto. ¿Por qué diría simplemente "oh, sin memoria / recursos - dele más memoria / recursos" sin examinar la causa?
Futuros visitantes y @sunnykeshri @JimmyBastos @BrotherDonkey @CodeMonkeyG , por mi cordura, dejen de propagar la corrección del límite de reloj.
Para los visitantes futuros, la solución de @pomber es objetivamente mucho mejor que aumentar el límite de visualización:
Agregue esto a su package.json:
"jest": { "modulePathIgnorePatterns": [ "node_modules" ] }
Esta debería ser la mejor respuesta. Gente, por favor golpee esto. ¿Por qué diría simplemente "oh, sin memoria / recursos - dele más memoria / recursos" sin examinar la causa?
Create React App limita las claves que se pueden usar dentro de la configuración de jest del paquete: ¿alguien ha encontrado una manera de resolver esto en una aplicación CRA?
Según mis hallazgos, no está relacionado con Jest en absoluto. En Linux (o Mac) tenemos un número máximo de observadores del sistema que podemos colocar en un nivel IO (según tengo entendido). Entonces, para proyectos grandes, parece que Jest está tratando de ver muchos archivos.
Arreglar:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Fuente: Node.JS Error: ENOSPC
Gracias resovel o problema já tava procurando a horas o que era esse rro
Según mis hallazgos, no está relacionado con Jest en absoluto. En Linux (o Mac) tenemos un número máximo de observadores del sistema que podemos colocar en un nivel IO (según tengo entendido). Entonces, para proyectos grandes, parece que Jest está tratando de ver muchos archivos.
Arreglar:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Fuente: Node.JS Error: ENOSPC
Solo una nota para mejorar, es mejor que indique a los usuarios que verifiquen que la marca / valor no existe ya para que no obtengan instancias duplicadas. Eso o usar algún tipo de herramienta con esto en mente.
Según mis hallazgos, no está relacionado con Jest en absoluto. En Linux (o Mac) tenemos un número máximo de observadores del sistema que podemos colocar en un nivel IO (según tengo entendido). Entonces, para proyectos grandes, parece que Jest está tratando de ver muchos archivos.
Arreglar:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Fuente: Node.JS Error: ENOSPC
Gracias por tu mejor respuesta.
Según mis hallazgos, no está relacionado con Jest en absoluto. En Linux (o Mac) tenemos un número máximo de observadores del sistema que podemos colocar en un nivel IO (según tengo entendido). Entonces, para proyectos grandes, parece que Jest está tratando de ver muchos archivos.
Arreglar:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Fuente: Node.JS Error: ENOSPC
gracias por tu respuesta
es trabajo para mi
Gracias @maraisr
Dado que los últimos comentarios han sugerido la solución anterior, y la solución posterior está comenzando a enterrarse, creo que es necesario reiterar a los futuros lectores (y a @ pradeepsrawat029 @ karsa87 @igorgoiis ) que primero debe probar la solución posterior si aplicable, que originalmente no era posible debido a un error de broma:
Para los visitantes futuros, la solución de @pomber es objetivamente mucho mejor que aumentar el límite de visualización:
Agregue esto a su package.json:
"jest": { "modulePathIgnorePatterns": [ "node_modules" ] }
Esta debería ser la mejor respuesta. Gente, por favor golpee esto. ¿Por qué diría simplemente "oh, sin memoria / recursos - dele más memoria / recursos" sin examinar la causa?
Pude solucionar este problema con sudo react-native start
Comentario más útil
Según mis hallazgos, no está relacionado con Jest en absoluto. En Linux (o Mac) tenemos un número máximo de observadores del sistema que podemos colocar en un nivel IO (según tengo entendido). Entonces, para proyectos grandes, parece que Jest está tratando de ver muchos archivos.
Arreglar:
Fuente: Node.JS Error: ENOSPC