Nothing in logs after build fails with "Error opening for web, check logs for details"

[AlanSl]

Summary

Many types of expo-cli build errors fail silently. The web UI toast pops up saying:

Error opening for web. Check logs for details.

...but there is nothing in the logs: nothing in the UI, nothing in the console, no log files created in .expo or anywhere else I can see. I've searched through Expo's docs to see if there are any other locations a log file might be written to, but I can't see anything.

Failing silently is a big problem because it leaves a developer no clues as to where the problem might be or where to starting debugging it.

Environment

  expo-env-info 1.0.2 environment info:
    System:
      OS: macOS 11.6.4
      Shell: 5.8 - /bin/zsh
    Binaries:
      Node: 16.1.0 - ~/.nvm/versions/node/v16.1.0/bin/node
      Yarn: 1.22.17 - ~/.nvm/versions/node/v16.1.0/bin/yarn
      npm: 8.5.3 - ~/.nvm/versions/node/v16.1.0/bin/npm
      Watchman: 2021.06.07.00 - /usr/local/bin/watchman
    Managers:
      CocoaPods: 1.10.1 - /usr/local/bin/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 21.2, iOS 15.2, macOS 12.1, tvOS 15.2, watchOS 8.3
      Android SDK:
        API Levels: 29, 30
        Build Tools: 29.0.2, 30.0.3
        System Images: android-29 | Intel x86 Atom_64, android-30 | Google APIs Intel x86 Atom
    IDEs:
      Xcode: 13.2.1/13C100 - /usr/bin/xcodebuild
    npmGlobalPackages:
      expo-cli: 5.3.0
    Expo Workflow: managed

Please specify your device/emulator/simulator platform, model and version

Web

Error output

None, that's the problem, it fails silently. Errors are being swallowed somewhere.

Reproducible demo or steps to reproduce from a blank project

It seems like errors in babel config are one of the types of error that Expo swallows, resulting in a failed build with no error messages.

Here's a couple of example things I tried while working on expo/expo#16673 that resulted in silent failure and nothing in the logs:

1. Adding certain unsupported keys in app.json; for example:

    "web": {
      "build": {
        "babel": {
          "plugins": [["react-native-web", { "commonjs": true }]]
        }
      }
    }

2. Some edits to babel loader config within webpack config, for example:

// in webpack.config.js
const createExpoWebpackConfigAsync = require('@expo/webpack-config')
const { getExpoBabelLoader } = require('@expo/webpack-config/utils')

module.exports = async function (env, argv) {
  const loader = getExpoBabelLoader(config)
  loader.use.options.configFile = './babel-web.config.js'

  const config = await createExpoWebpackConfigAsync(env, argv)
  return config
}

To re-iterate: the problem is not that these fail, I'm sure I've done something legitimately wrong in each case.

The problem is that they fail silently with nothing output to any logs (despite the UI toast telling me to look in the toast).

Errors in other steps of the build are output to the console window that ran the build script; but for these nothing is logged.

For example, brute force debugging suggests calling getExpoBabelLoader before createExpoWebpackConfigAsync crashes. The problem is, the error message that would clarify this and saved a lot of trial-and-error is swallowed and is never logged.

[revanth7999]

Any solution for this? Me too facing the same issue after updating the expo sdk version to 40.

[oliviercperrier]

Same here, when developing on the web, i have error in my code, but i still see Web Bundling complete and i'm able to use the app.

Thats not very dev friendly, i just don't know if there are errors in my code..

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[AlanSl]

Not stale, bot.

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale. Please open a new issue if you believe you are encountering a related problem.