Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metro takes too long in Loading dependency graph and changes are not seen #434

Closed
JaEdmuva opened this issue Jul 25, 2019 · 3 comments
Closed

Comments

@JaEdmuva
Copy link

JaEdmuva commented Jul 25, 2019

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
Metro takes too long in Loading dependency graph... at least 1 minute or more
Additionally, when there is an error involving file/folder names/structure, metro won't update fixes and work normally. Restart is required, which again takes sooo long.

If the current behavior is a bug, please provide the steps to reproduce and a minimal repository on GitHub that we can yarn install and yarn test.
simply start fresh with:
react-native init someProject
react-native start

What is the expected behavior?
Metro should not take so long to load dependencies and expose changes to app files

Please provide your exact Metro configuration and mention your Metro, node, yarn/npm version and operating system.
Metro from latest available version:
react-native-cli: 2.0.1
react-native: 0.60.4
MacOS Mojave v10.14.6

@JaEdmuva JaEdmuva changed the title Metro takes too long in Loading dependency graph Metro takes too long in Loading dependency graph and changes are not seen Jul 25, 2019
@snc001
Copy link

snc001 commented Aug 1, 2019

I had the same issue and had downgraded node from latest version to the LTS one which is 10.16.1.
It has fixed the long load time and major RAM leak issue for me here.

@mikehardy
Copy link
Contributor

mikehardy commented Aug 9, 2019

you can either use node <= v12.4.0, likely node >= 12.9.0 (assuming it gets the V8 sync nodejs/node#28955), or (new info) based on my testing just now you might try a workaround in jest-haste-map documented here with an attached patch-package compatible patch until jest-haste-map has the workaround integrated

jestjs/jest#8787 (comment)

I think this is probably a duplicate though though and should be closed, at least vs #429 and quite a few others

@JaEdmuva
Copy link
Author

got ya, I'll close this issue. Hope that node fix helps

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants