eas build fail - showing "Cannot read properties of null (reading 'children')"

  • Managed workflow
  • eas-cli version 3.4.1
  • I’ve tried
    = remove package-lock.json and node modules folder
    = then npm install
    = then run eas build
    = but showing error “Cannot read properties of null (reading ‘children’)” during prebuild

Hi @fiqahgcr2

What dependencies and devDependencies do you have in package.json?

this is my package.json

1 Like

Please paste it as text. I can’t do much with it as images.

Just having a look through your dependencies, this is what I see:

  • You should not have expo-cli installed as a dependency or devDependency. Rather install it globally
  • Do you need to explicitly install @expo/config-plugins and @expo/prebuild-config?
  • You have a mixture of different versions of React Navigation packages installed
  • There’s some possible duplication. Not necessarily a problem, but maybe you could get rid of some unnecessary dependencies. e.g. expo-file-system and react-native-fs, expo-image-picker and react-native-image-picker
  • Do you need expo-permissions? This was deprecated a while ago in favour of using things like ImagePicker.requestMediaLibraryPermissionsAsync()

Thanks for the answer.
I’ll try follow your suggestion.

I have the same problem, this is my package.json:

Please post those as text to make it easier for someone else to test this.

Also, do you get any warnings if you run npx expo-doctor?

npx expo-doctor says that there are no issues.

"dependencies": {
    "@expo/webpack-config": "^0.17.2",
    "@react-native-async-storage/async-storage": "~1.17.3",
    "@react-navigation/native": "^6.1.2",
    "@react-navigation/native-stack": "^6.9.8",
    "axios": "^1.3.2",
    "expo": "~47.0.12",
    "expo-av": "~13.0.3",
    "expo-linear-gradient": "~12.0.1",
    "expo-status-bar": "~1.4.2",
    "jsonwebtoken": "^9.0.0",
    "lottie-react-native": "5.1.4",
    "react": "18.1.0",
    "react-hook-form": "^7.43.0",
    "react-native": "0.70.5",
    "react-native-progress": "^5.0.0",
    "react-native-safe-area-context": "4.4.1",
    "react-native-screens": "~3.18.0",
    "react-native-webview": "11.23.1",
    "rn-placeholder": "^3.0.3",
    "socket.io-client": "^4.6.1"
  },
  "devDependencies": {
    "@babel/core": "^7.12.9",
    "@types/jsonwebtoken": "^9.0.1",
    "@types/react-native": "^0.71.1",
    "babel-plugin-module-resolver": "^5.0.0",
    "ts-node": "^10.9.1",
    "typescript": "^4.9.4"
  },

Are you using this? You don’t have react-dom or react-native-web, so maybe not unless maybe you’re bundling some stuff to load in a webview? If you’re not using it you might want to remove it. It should of course not be causing problems, but generally best to remove things you don’t need. Also, if you do need it it really belongs in devDependencies rather than dependencies.

But that’s not the cause of the problem.

If I try this with your deps it works for me. I was using yarn instead of npm, though.
Then I removed yarn.lock and ran npm install. That gave me the same error. I checked npm’s debug log and that pointed me at this part of npm’s code:

      // First, see if it's ok to just replace the peerSet entirely.
      // we do this by walking out from the entryEdge, because in a case like
      // this:
      //
      // v -> PEER(a@1||2)
      // a@1 -> PEER(b@1)
      // a@2 -> PEER(b@2)
      // b@1 -> PEER(a@1)
      // b@2 -> PEER(a@2)
      //
      // root
      // +-- v
      // +-- a@2
      // +-- b@2
      //
      // Trying to place a peer group of (a@1, b@1) would fail to note that
      // they can be replaced, if we did it by looping 1 by 1.  If we are
      // replacing something, we don't have to check its peer deps, because
      // the peerDeps in the placed peerSet will presumably satisfy.
      const entryNode = entryEdge.to
      const entryRep = dep.parent.children.get(entryNode.name)
      if (entryRep) {
        if (entryRep.canReplace(entryNode, dep.parent.children.keys())) {
          continue
        }
      }

in particular, this line:

      const entryRep = dep.parent.children.get(entryNode.name)

Since this seems to have something to do with peer dependencies I tried running it with the --legacy-peer-deps option in case it helped, and indeed it did!

So it seems there’s something dodgy going on with the peer dependencies of one or more of the packages you have installed, and in addition there’s a possible npm bug.

As a workaround, you could ensure that npm install runs with the legacy-peer-deps option set to true:

Thank you for your help in solving the problem I was having with my package.json file. Your suggestion to use the --legacy-peer-deps option when running npm install worked perfectly and allowed me to get everything up and running smoothly. I really appreciate you taking the time to dig into the issue and find a solution, and I’m grateful for your expertise and willingness to share it with others.

1 Like