New project, eas build -ios freezes

Expo Application Services (EAS)
1

Hi,

I’m having trouble building a new ios project.

What I did:

  1. expo init iostest
  2. cd iostest
  3. npx expo-env-info tells it is a bare project and I wanted a managed one so I renamed ios and android folders, npx expo-env-info say it is managed now .
  4. eas build:configure and selected All.
  5. eas build --profile preview --platform ios

And freezes after:

Same project --platform android builds ok.

I’m making some obvious mistake?

Thanks in advance for any help.

This system:

expo-env-info 1.0.3 environment info:
System:
OS: Windows 10 10.0.16299
Binaries:
Node: 16.14.2 - C:\nodejs\node.EXE
Yarn: 1.19.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
npm: 8.7.0 - C:\nodejs\npm.CMD
npmPackages:
expo: 44.0.2 => 44.0.2
react: 17.0.1 => 17.0.1
react-dom: 17.0.1 => 17.0.1
react-native: 0.64.3 => 0.64.3
react-native-web: 0.17.1 => 0.17.1
Expo Workflow: managed

eas --version
eas-cli/0.52.0 win32-x64 node-v16.14.2

expo doctor

WARNING: We recommend using PowerShell or Bash via WSL 2 for development with expo-cli on Windows. You may encounter issues using cmd.exe.

:tada: Didn’t find any issues with the project!

2

see this warning at the bottom:

WARNING: We recommend using PowerShell or Bash via WSL 2 for development with expo-cli on Windows. You may encounter issues using cmd.exe.

3

Thanks for looking into this.

I tried Powershell but same result. It finally worked, the problem was that expo-modules-autolinking/mergeLinkingOptionsAsync/resolveSearchPathsAsync never returned.
It is called from @expo/prebuild-config.
I skipped that call as all the project files are in the same folder, but more research is needed.

4

do you have eas-cli installed locally in your project or globally?

5

Globally.

6

can you run it again with the DEBUG=* environment variable set?

7

Patched or original version?

8

not sure what you mean by patched :slight_smile:

edit: oh i understood your other comment now - you commented out that line to get past it. without the patch would be interesting

9

can you share information about the full directory path that you are running this from? also, given that you’re comfortable patching this, can you also add some logging statements resolveSearchPathsAsync to see what is happening inside of it?

11

I narrowed it down to “findDefaultPathsAsync” in expo-modules-autolinking/build/autolinking. Sorry I couldn’t find that repository. The loops never exit when an empty directory is reached.

Project directory is “F:\expoprjs\iostest2” = cwd.

async function findDefaultPathsAsync(cwd) {
    const paths = [];
    let dir = cwd;
    let pkgJsonPath;
    while ((pkgJsonPath = await (0, find_up_1.default)('package.json', { cwd: dir }))) {
        dir = path_1.default.dirname(path_1.default.dirname(pkgJsonPath));		
 	    console.log('findDefaultPathsAsync dir: ' + dir + ' paths: ' + JSON.stringify(paths));   //**//
        paths.push(path_1.default.join(pkgJsonPath, '..', 'node_modules'));
    }
    return paths;
}

Log is:

findDefaultPathsAsync dir: F:\expoprjs paths:
findDefaultPathsAsync dir: F:\ paths: [“F:\expoprjs\iostest2\node_modules”]
findDefaultPathsAsync dir: F:\ paths: [“F:\expoprjs\iostest2\node_modules”,“F:\node_modules”]
findDefaultPathsAsync dir: F:\ paths: [“F:\expoprjs\iostest2\node_modules”,“F:\node_modules”,“F:\node_modules”]
…

This provisory patch works well:

async function findDefaultPathsAsync(cwd) {
    const paths = [];
    let dir = cwd;
    let parse;                                                //**//
    let pkgJsonPath;
    while ((pkgJsonPath = await (0, find_up_1.default)('package.json', { cwd: dir }))) {
        dir = path_1.default.dirname(path_1.default.dirname(pkgJsonPath));		
 	    console.log('findDefaultPathsAsync dir: ' + dir + ' paths: ' + JSON.stringify(paths));   //**//
        paths.push(path_1.default.join(pkgJsonPath, '..', 'node_modules'));
        parse = path_1.default.parse(dir);
        if (parse.root === dir) break;   //**//
    }
    return paths;
}
1 Like
12

thank you for the investigation! the package lives here btw: expo/packages/expo-modules-autolinking at main · expo/expo · GitHub

i’m glad you’re able to work around this, we’ll investigate a fix

13

Thank you for reviewing this issue!

1 Like
14

Hi, thank you for the report, investigation and fix proposal! :pray:
I think this issue is not really specific to Windows — I suspect you just have the package.json at the root path (F:\package.json) and that’s the only case where the loop may not exit. Is that right?
On macOS it’s not possible to write to /package.json though, so that’s probably why we haven’t encountered this issue before :sweat_smile:
I submitted a PR to fix this: [autolinking] Fixed an infinite loop when the package.json is placed at the root path by tsapeta · Pull Request #17440 · expo/expo · GitHub and I think we’ll publish it later this week.

1 Like
15

Hi, you’re right! There was an unrelated old package.json in the root directory. :+1:
It’s good that there is already PR to fix this.
I wonder why -p android worked fine without fix :thinking:
Anyway, thanks for checking it out!