Am I supposed to wait on "Loading dependency graph ..."


#1

Upon creating a new project in Expo XDE, I get the following in the React Native Packager:

Loading dependency graph, done.
eLoading dependency graph…e

No output after that, am I supposed to wait on “Loading dependency graph …e”?


#2

Hi, the packager won’t do anything from there until it receives a request from a device to load the app. Try opening the project on a device (via the Device or Send Link buttons in XDE).

Also, sorry about the weird “e” typo, there might be some edge case in our logging code we need to address.


#3

Is there a reason why it does not just start “Transforming modules”? It would save time when reloading when it just would start doing that work immediately?


#4

I am unable to click on one of those buttons for my device to request the app


#5

Good call, I created an issue for this suggestion.


#6

I suppose I have a network issue at my workplace. When I started a new project the necessary files were downloading for 30 minutes. So the point might be that there is some background downloading process after ‘Dependency graph loaded’ stage. If so it would be nice to have an additional indicator for that.


#7

I am having this same problem. It occurs in every new expo project I create. I am pretty confident that it has to do with node and some of it’s dependencies. I have tried a number of different node management solutions (n, nvm, etc) but still haven’t found an implementation that solved the problem.

To be exact, the project is failing to build the dependency graph for any React Native project. Even if I create a new react native project, it will get stuck building the dependency graph. For this reason, I am sure it is a computer issue and not a project issue

FTR: I currently have a 2014 Macbook pro, node version v7.7.3, npm v4.1.2, and all of my apps are up-to-date.


#8

@juniorthelb Here are a couple of things you could try:

  • Install Node with nvm and set it to be your default version of Node. If you installed Node with the installer from nodejs.org I’d recommend removing it. In the past at least, that copy of Node required running sudo to install global modules. I find that using nvm or Homebrew’s versions of Node are easier to work with.
  • If you use nvm, make sure that it’s set up to run each time you open a new shell. For example, if you open a new terminal window and run which node, you should get something like /Users/you/.nvm/versions/node/v8.8.1/bin/node.
  • Try using Yarn instead of npm.
  • Delete node_modules and run yarn to install them again. Once things are in a working state, commit yarn.lock to Git/Mercurial/whatever.
  • Install Watchman on your computer with brew install watchman.
  • Clear several caches related to the React Native packager, instructions here.

#9

@ide

Thanks for the response. I tried deleting the node_modules and reinstalling
with yarn(Yarn is v0.27.5). I also cleared all the caches related to the RN
Packager. I did all these and followed your instructions a couple times,
but I’m still stuck with the same issue (getting stuck on Dependency graph
loaded without the option to launch the simulator or share to a device).

I also tried firing up expo in the terminal instead of using XDE - same
issue. When I run it with XDE I’m not getting any warnings or errors.

I also did npm install --save react-navigation@1.0.0-beta.11 as suggested
by @joelwass.

No luck with any of these attempts unfortunately. Do you have any other
ideas? I appreciate the help


#10

I have the same problem Any sulotions?


#11

I am having the same problem. I removed everything node, npm, yarn and started from scratch using nvm… no luck. I restarted the computer too. no luck.


#12

I just ran into this today, and managed to find a workaround. (TL/DR: make sure localhost exists in your /etc/hosts file).

In my case, I installed Expo on a brand new macbook and all my existing projects started to fail miserably with the same symptoms.

Digging a bit deeper, I found a bug in the xdl library under _waitForRunningAsync.

The exception handler doesn’t think about what type of exception is being raised, since e.code = ECONNREFUSED is expected behavior. So if your Mac doesn’t resolve localhost, this will make _waitForRunningAsync go into an infinite recursion loop.

e.code = ENOTFOUND should be caught differently, and surfaced (maybe as an error message telling the user the machine is misconfigured). If I have time this weekend I’ll put a PR together.


#13

Tried jameswann solution, added “127.0.0.1 localhost” in /etc/hosts file, it works now! Thanks jameswann