Jest: Bug: o modo de observação no Linux causa um erro ENOSPC Node.js

Isso significa que não há espaço em sua unidade. Limpe seu disco.

@cpojer não tenho certeza se você leu a edição, mas;

Espaço livre em disco: df -h / (11% usado)

foi mencionado lá - o espaço em disco, embora relatado como o problema, na verdade não é o problema.

Bump @cpojer

Estou tendo o mesmo problema e definitivamente há espaço livre em disco

Infelizmente não temos recursos para depurar isso no Linux. Se você tiver tempo e puder dar uma olhada e nos ajudar com um pull request para consertá-lo, será muito grato.

@cpojer Vou dar uma olhada - mas também acredito que não se limite ao sistema operacional Linux. Independentemente disso, você se importaria de reabrir este problema?

Pelas minhas descobertas, não tem nada a ver com Jest. No Linux (ou Mac), temos um número máximo de observadores do sistema que podemos colocar em um nível de IO (pelo meu conhecimento). Portanto, para grandes projetos, parece que Jest está tentando assistir a muitos arquivos.

Consertar:

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

Fonte: Node.JS Erro: ENOSPC

Obrigado por investigar, se você instalar o watchman, deve funcionar.

Recentemente, mudei do Windows 7 para o Ubuntu 16.04.2 LTS e Jest estava funcionando muito bem no Windows, mas não funcionou no Linux pelos mesmos motivos listados acima. Ele só parece falhar se você adicionar a sinalização --watch .

Em primeiro lugar, segui o conselho de documentos e executei jest --watch novamente e recebi os seguintes erros:

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.

Isso foi útil porque diz a você o que fazer, então usei a correção de @maraisr e jest agora está trabalhando no Ubuntu: tada:: cervejas:

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

Obrigado por descobrir isso @maraisr @cpojer : +1: Você acha que algo deveria ser adicionado ao site do

Obrigado mano @maraisr

@maraisr você sabe se existe uma versão sem sudo dessa solução, por acaso?

@vspedr não tenho certeza - posso dar uma olhada!

Mas estamos mexendo nos arquivos de sistema lá, então, por segurança, você precisa de permissões elevadas. Se você pode se tornar um sudoer, acredito que pode executar esses comandos sem sudo.

Mas sim - vou dar uma olhada e ver o que posso fazer.

Pode ser que eu esteja faltando alguma coisa ... mas por que jest precisa assistir alguma coisa em meu diretório node_modules ?
Como posso configurá-lo para pular node_modules ?

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

@SimenB , como vejo watchPathIgnorePatterns pula arquivos apenas depois que o próprio relógio está instalado e funcionando, é por isso que o início do relógio pode demorar muito e às vezes pode lançar ENOSPC

Ah ok. Um PR respeitando watchPathIgnorePatterns ao configurar observadores seria bom :)

@SimenB, você pode me indicar o local no código-fonte onde começa a assistir diretamente? Tenho dificuldade em encontrar este lugar

Descubra que o observador está usando o HasteMap como uma fonte de todos os arquivos que devem ser observados, e a questão agora em processo de construção do HasteMap.
O HasteMap respeita a opção modulePathIgnorePatterns, mas não é lógico usar essa opção com base na descrição dos documentos:

Uma matriz de strings de padrão regexp que correspondem a todos os caminhos do módulo antes que esses caminhos sejam considerados 'visíveis' para o carregador do módulo. Se o caminho de um determinado módulo corresponder a qualquer um dos padrões, ele não será capaz de require () no ambiente de teste.

Estou certo?

@maraisr

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

esta solução não funciona no meu mac os 10.13.4 ele retorna o erro abaixo

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

Não vejo por que esse bug é "Fechado". Forçar o usuário a sudo para uma tarefa mundana é certamente um bug.

É um bug exclusivo do Jest: mocha, guard, etc. todos os _subdiretórios_ específicos, não . , para evitar esse problema. (A lista de subdiretórios pode ser opcional.)

Em 21 de brincadeira, eu nunca tive esse problema. O vscode está competindo de brincadeira para assistir os arquivos. quando fecho o vscode, o jest começa a funcionar corretamente.

Eu estava tendo esse problema quando tinha duas instâncias de VSCode abertas.

Reabra ou adicione a correção à solução de problemas para teste.

Isso me levou muito tempo para encontrar e finalmente consertar. Comecei a fazer soluções alternativas novamente e novamente. Obrigado @ samit4me !

Eu tive isso com 2 instâncias do VSCode aberto, o que faz todo o sentido.

Para fugir desse bug, basta usar sublime / atom / gedit. Ou você pode fechar o VSCode durante a construção / depuração.

lsof | wc -l
pode lançar luz sobre a fonte do problema.
Qualquer programa, seja um navegador ou construído com um mecanismo da web interno (ou seja, código VS), aumenta drasticamente o número de descritores de arquivos abertos (cerca de 30.000 e mais por programa).
Não vejo uma solução alternativa confiável, porque. a tecnologia da web se tornou onipresente

Felicidades pelo ponto na direção certa sobre isso. Tive o mesmo problema com a falha do relógio, mas, neste caso, apenas uma instância do VSCode em execução. Fechar isso, executar meu projeto e reabrir, resolveu.

IMO, é inaceitável que haja um relógio em node_modules

É principalmente trabalho (e um monte de arquivos excluídos) do mecanismo da web, mas não de node_modules, que bloqueia nós livres para o observador.

Recebi este erro ao atualizar as dependências do projeto. Para resolver, acabei de remover e instalar o node_modules

Muito obrigado

@maraisr Ótimo, echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p funcionou para mim no Ubuntu 18.04.1 LTS

@maraisr Obrigado por corrigir funciona perfeitamente no ubuntu 18 como @xameeramir diz

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p corrigiu para mim também: +1:

Esteja ciente de que /etc/sysctl.conf é normalmente sobrescrito durante a atualização (por exemplo, do Ubuntu 16 para 18 LTS) e removerá o limite superior. Fui avisado sobre isso, mas é fácil passar despercebido em um mar de outros avisos semelhantes. Mesmo que eu _visse_ o max_user_watches diff, ainda estava confuso esta manhã quando me deparei com o erro pela primeira vez, pois não é óbvio que essas coisas estejam conectadas. No entanto, assim que cheguei a esta página de problema, ficou claro o que eu precisava corrigir.

Viva por resolver um problema que eu consertei há dois anos: rindo:

Coisa engraçada sobre fs.inotify.max_user_watches=524288
No meu caso, parece que o projeto é grande o suficiente para que 524288 não seja grande o suficiente para ser um número. Então ... bem, fs.inotify.max_user_watches=2048000 ajudou.
Também pode estar relacionado à questão de abrir um monte de coisas no código vs na lateral.

Conseguir isso no ubuntu 18.10 quando executo "npm start" no meu app criar-reagir virgem intocado
TRABALHADO!!!
SOLUÇÃO
echo fs.inotify.max_user_watches = 2048000 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Pelo que vale a pena: talvez seja relacionado ao ambiente (módulo X vs módulo Y).

Tenho 2 aplicativos ReactNative com 2 configurações diferentes. Principalmente porque um deles usa React-Native-Camera que ainda não está pronto para as versões RN mais recentes (ou seja: o Gradle mais recente e tal ambiente). O outro é uma demonstração para testar a versão e o ambiente mais recentes do RN.

O aplicativo que usa React-Native-Camera compila perfeitamente (--variant = release) no Linux . O outro obteve o erro ENOSPC . A correção "fs.inotify.max_user_watches" funcionou. Eu estava tipo "hein?". Conforme descrito por outro, tenho toneladas de gigabytes no NAS ...

Aqui está o "package.json" de ambos os aplicativos.

Talvez você encontre algo útil.
App 1 (câmera):

{
  "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 (demonstração de teste):

{
  "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,
obrigado trabalhos !!!

apenas correndo enquanto o sudo funcionava para mim

@ 4E71-NOP Eu vi a mesma coisa. Assim que atualizamos de RN 0,51 para 0,57, começamos a ter esse problema. Aumentar o limite de inotify ajudou

Eu corro com sudo ... e funciona para mim

echo fs.inotify.max_user_watches = 524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Isso me ajudou no UBUNTU 18.10

Muito Obrigado. Mas assim como @adamhooper mencionou antes, Forcing the user to sudo for a mundane task is certainly a bug.

Alguma ideia para o usuário regular?

echo fs.inotify.max_user_watches = 524288 |

Pelas minhas descobertas, não tem nada a ver com Jest. No Linux (ou Mac), temos um número máximo de observadores do sistema que podemos colocar em um nível de IO (pelo meu conhecimento). Portanto, para grandes projetos, parece que Jest está tentando assistir a muitos arquivos.

Consertar:

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

Fonte: Node.JS Erro: ENOSPC

Resolvi perfeitamente o meu problema, muito obrigado!

Eu corrigi-lo excluindo node_modules com a configuração modulePathIgnorePatterns .

Adicione isto ao seu package.json:

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

Funcionou como um encanto. Obrigado @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 futuros visitantes, a solução de @pomber é objetivamente muito melhor do que aumentar o limite de observação:

Adicione isto ao seu package.json:

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

Pelas minhas descobertas, não tem nada a ver com Jest. No Linux (ou Mac), temos um número máximo de observadores do sistema que podemos colocar em um nível de IO (pelo meu conhecimento). Portanto, para grandes projetos, parece que Jest está tentando assistir a muitos arquivos.

Consertar:

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

Fonte: Node.JS Erro: ENOSPC

Isso corrigiu um problema que estava enfrentando com o Vue ao executar npm run serve Obrigado pela sugestão @maraisr

@pomber Obrigado, resolveu meu problema no Fedora sem aumentar o limite do sistema.

Obrigado @maraisr , resolveu meu problema :)

Muito Obrigado! @maraisr

Sua solução funcionou para mim, @maraisr!
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Obrigado!

Este foi o meu erro para quem está interessado:
Os registros do seu projeto serão exibidos abaixo. Pressione Ctrl + C para sair.
(nó: 19425) UnhandledPromiseRejectionWarning: Erro: ENOSPC: Limite do sistema para o número de observadores de arquivos atingido, observe '/ home / claire / Documents / my-app-name'
em FSWatcher.start (internal / fs / watchers.js: 165: 26)
em Object.watch (fs.js: 1274: 11)
em NodeWatcher.watchdir (/home/claire/Documents/my-app-name/node_modules/sane/src/node_watcher.js:175:20)
no novo NodeWatcher (/home/claire/Documents/my-app-name/node_modules/sane/src/node_watcher.js:45:8)
em createWatcher (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:780:23)
em Array.map ()
em HasteMap._watch (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:936:44)
em _buildPromise._buildFileMap.then.then.hasteMap (/home/claire/Documents/my-app-name/node_modules/jest-haste-map/build/index.js:355:23)
em processTicksAndRejections (internal / process / next_tick.js: 81: 5)
(nó: 19425) UnhandledPromiseRejectionWarning: Rejeição de promessa não tratada. Esse erro foi originado ao lançar dentro de uma função assíncrona sem um bloco catch ou ao rejeitar uma promessa que não foi tratada com .catch (). (id de rejeição: 1)
(nó: 19425) [DEP0018] Aviso de depreciação: Rejeições de promessa não tratadas foram descontinuadas. No futuro, as rejeições de promessa que não são tratadas encerrarão o processo Node.js com um código de saída diferente de zero.
ENOSPC: Limite do sistema para o número de observadores de arquivos atingido, observe '/ home / claire / Documents / my-app-name'
ENOSPC: Limite do sistema para o número de observadores de arquivos atingido, observe '/ home / claire / Documents / my-app-name'

Eu corrigi-lo excluindo node_modules com a configuração modulePathIgnorePatterns .

Adicione isto ao seu package.json:

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

depois disso, apenas remova a pasta node_modules e execute npm install novamente.

"modulePathIgnorePatterns": [
      "node_modules"
    ]

esta é a verdadeira resposta

Se você se deparar com esse problema de maneira consistente e não puder ignorar node_modules , a instalação do Watchman ajudará:
https://facebook.github.io/watchman/

Existem otimizações específicas do Watchman no Jest, portanto, ele também irá melhorar significativamente o seu tempo de inicialização para grandes projetos.

Daqui para frente, tentarei não assistir node_modules automaticamente, pois isso causaria esse tipo de erro (por exemplo: nenhum Watchman e nem no Darwin, portanto, não pode usar fsevents ).

Oh, ei @scotthovestadt! Espero que estejas bem!

Para futuros visitantes, a solução de @pomber é objetivamente muito melhor do que aumentar o limite de observação:

Adicione isto ao seu package.json:

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

Esta deve ser a melhor resposta. Pessoas - por favor, esbarrem nisso. Por que você simplesmente diria "oh, sem memória / recursos - dê mais memória / recursos" sem examinar a causa?

Infelizmente não temos recursos para depurar isso no Linux. Se você tiver tempo e puder dar uma olhada e nos ajudar com um pull request para consertá-lo, será muito grato.

O Linux é o padrão de fato para todos os desenvolvedores profissionais. Você realmente se preocupa mais com os usuários do Windows e do Mac? Isso é uma vergonha

@maraisr obrigado. Resolvi o problema. :dançarino:

Para futuros visitantes, a solução de @pomber é objetivamente muito melhor do que aumentar o limite de observação:

Adicione isto ao seu package.json:

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

Esta deve ser a melhor resposta. Pessoas - por favor, esbarrem nisso. Por que você simplesmente diria "oh, sem memória / recursos - dê mais memória / recursos" sem examinar a causa?

Apenas uma nota para registro: a presente correção apropriada não funcionou até o # 7585 que corrigiu o # 7544.

pode haver alguns problemas de permissão, tente Sudo npm start

Este comando aumentará o número de observadores permitidos:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Fonte

Pelas minhas descobertas, não tem nada a ver com Jest. No Linux (ou Mac), temos um número máximo de observadores do sistema que podemos colocar em um nível de IO (pelo meu conhecimento). Portanto, para grandes projetos, parece que Jest está tentando assistir a muitos arquivos.

Consertar:

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

Fonte: Node.JS Erro: ENOSPC

@maraisr Obrigado, sua solução funcionou perfeitamente no Ubuntu 18.04

Pelas minhas descobertas, não tem nada a ver com Jest. No Linux (ou Mac), temos um número máximo de observadores do sistema que podemos colocar em um nível de IO (pelo meu conhecimento). Portanto, para grandes projetos, parece que Jest está tentando assistir a muitos arquivos.

Consertar:

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

Fonte: Node.JS Erro: ENOSPC

Obrigado, isso resolveu meu problema.

Futuros visitantes e @sunnykeshri @JimmyBastos @BrotherDonkey @CodeMonkeyG , para minha sanidade, pare de propagar a correção do limite de vigilância.

Para futuros visitantes, a solução de @pomber é objetivamente muito melhor do que aumentar o limite de observação:

Adicione isto ao seu package.json:

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

Esta deve ser a melhor resposta. Pessoas - por favor, esbarrem nisso. Por que você simplesmente diria "oh, sem memória / recursos - dê mais memória / recursos" sem examinar a causa?

Futuros visitantes e @sunnykeshri @JimmyBastos @BrotherDonkey @CodeMonkeyG , para minha sanidade, pare de propagar a correção do limite de vigilância.

Para futuros visitantes, a solução de @pomber é objetivamente muito melhor do que aumentar o limite de observação:

Adicione isto ao seu package.json:

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

Esta deve ser a melhor resposta. Pessoas - por favor, esbarrem nisso. Por que você simplesmente diria "oh, sem memória / recursos - dê mais memória / recursos" sem examinar a causa?

Criar aplicativo React limita as chaves que podem ser usadas na configuração do pacote jest - alguém encontrou uma maneira de resolver isso em um aplicativo CRA?

Pelas minhas descobertas, não tem nada a ver com Jest. No Linux (ou Mac), temos um número máximo de observadores do sistema que podemos colocar em um nível de IO (pelo meu conhecimento). Portanto, para grandes projetos, parece que Jest está tentando assistir a muitos arquivos.

Consertar:

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

Fonte: Node.JS Erro: ENOSPC

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

Pelas minhas descobertas, não tem nada a ver com Jest. No Linux (ou Mac), temos um número máximo de observadores do sistema que podemos colocar em um nível de IO (pelo meu conhecimento). Portanto, para grandes projetos, parece que Jest está tentando assistir a muitos arquivos.

Consertar:

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

Fonte: Node.JS Erro: ENOSPC

Apenas uma observação para melhoria, talvez seja melhor instruir os usuários a verificar se o sinalizador / valor ainda não existe, para que não obtenham instâncias duplicadas dele. Isso ou usar algum tipo de ferramenta para isso.

Pelas minhas descobertas, não tem nada a ver com Jest. No Linux (ou Mac), temos um número máximo de observadores do sistema que podemos colocar em um nível de IO (pelo meu conhecimento). Portanto, para grandes projetos, parece que Jest está tentando assistir a muitos arquivos.

Consertar:

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

Fonte: Node.JS Erro: ENOSPC

Obrigado pela sua melhor resposta.

Pelas minhas descobertas, não tem nada a ver com Jest. No Linux (ou Mac), temos um número máximo de observadores do sistema que podemos colocar em um nível de IO (pelo meu conhecimento). Portanto, para grandes projetos, parece que Jest está tentando assistir a muitos arquivos.

Consertar:

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

Fonte: Node.JS Erro: ENOSPC

obrigado pela sua resposta
é trabalho para mim

Obrigado @maraisr

Como os últimos comentários sugeriram a solução alternativa anterior e a correção posterior está começando a ficar enterrada, sinto que é necessário reiterar para os leitores futuros (e @ pradeepsrawat029 @ karsa87 @igorgoiis ) que você deve primeiro tentar a correção posterior se aplicável, o que originalmente não era possível por causa de um bug de brincadeira:

Para futuros visitantes, a solução de @pomber é objetivamente muito melhor do que aumentar o limite de observação:

Adicione isto ao seu package.json:

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

Esta deve ser a melhor resposta. Pessoas - por favor, esbarrem nisso. Por que você simplesmente diria "oh, sem memória / recursos - dê mais memória / recursos" sem examinar a causa?

Consegui corrigir esse problema com sudo react-native start