#2852·cli

Tons of errors are ignored

Author: GNUGradynCreated Sep 10, 2026Updated Sep 10, 2026

Hello. This bug is to keep track of a multitude of small issues where errors are silently ignored or misinterpreted. There are several pull requests fixing some of them already but this one does not appear to have a PR yet and is a great example. From isPackagerRunning.ts:

async function isPackagerRunning(
  packagerPort: string | number = process.env.RCT_METRO_PORT || '8081',
): Promise<
  | {
      status: 'running';
      root: string;
    }
  | 'not_running'
  | 'unrecognized'
> {
  try {
    const {data, headers} = await fetch(
      `http://localhost:${packagerPort}/status`,
    );

    try {
      if (data === 'packager-status:running') {
        return {
          status: 'running',
          root: headers.get('X-React-Native-Project-Root') ?? '',
        };
      }
    } catch (_error) {
      return 'unrecognized';
    }
    return 'unrecognized';
  } catch (_error) {
    return 'not_running';
  }
}

Two issues here had me chasing false starts with another bug:

  • Any error interpreting the data (e.g. data is undefined) is treated as undefined. This will likely be wrong so at minimum there should be a visible by default warning in this scenario
  • Any issue during this entire process that isn't explicitly handles is treated as not_running. Again this might be ok if the unrecognized error were visible, since that will not always be the correct thing to do

Bit of a side note with this snippet, there is a lot of unnecessary complexity that stems from the strange shape of this methods return type. We might want to make it something like

{status: 'running' | 'not_running' | 'unrecognized', root: string?} 

and/or use an enum for the status. This is just "bug prone" not itself a bug, and we would need to refractor this area anyway, so let me know if we feel like this should be its own bug or if we should ignore it.

Source: react-native-community/cli