Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HELP error index.js: The "id" argument must be of type string. Received undefined. #1017

Closed
walidhousni30 opened this issue Jun 27, 2023 · 26 comments

Comments

@walidhousni30
Copy link

Description

Since i upgraded my react native app to 0.72 i cant run the app anymore .i ve tried to dedupe the duplicates of metro , but here i am stuck with this error .

image

React Native Version

0.72.0-rc.6

Output of npx react-native info

System:
OS: macOS 13.4
CPU: (8) arm64 Apple M1
Memory: 126.47 MB / 8.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 20.3.1
path: /opt/homebrew/bin/node
Yarn:
version: 4.0.0-rc.45
path: ~/Desktop/projects/labelvie/fid-mobile-copy/node_modules/.bin/yarn
npm:
version: 9.6.7
path: /opt/homebrew/bin/npm
Watchman:
version: 2023.06.12.00
path: /opt/homebrew/bin/watchman
Managers:
CocoaPods:
version: 1.12.1
path: /Users/walidhousni/.rvm/gems/ruby-3.2.2/bin/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 22.4
- iOS 16.4
- macOS 13.3
- tvOS 16.4
- watchOS 9.4
Android SDK:
API Levels:
- "31"
- "33"
Build Tools:
- 30.0.2
- 30.0.3
- 33.0.0
- 33.0.2
- 34.0.0
System Images:
- android-33 | Google TV Intel x86 Atom
- android-33 | Google APIs ARM 64 v8a
Android NDK: Not Found
IDEs:
Android Studio: 2022.2 AI-222.4459.24.2221.10121639
Xcode:
version: 14.3.1/14E300c
path: /usr/bin/xcodebuild
Languages:
Java:
version: 11.0.19
path: /usr/bin/javac
Ruby:
version: 3.2.2
path: /Users/walidhousni/.rvm/rubies/ruby-3.2.2/bin/ruby
npmPackages:
"@react-native-community/cli":
installed: 10.0.0
wanted: 10.0.0
react:
installed: 18.2.0
wanted: 18.2.0
react-native:
installed: 0.72.0-rc.6
wanted: 0.72.0-rc.6
react-native-macos: Not Found
npmGlobalPackages:
"react-native": Not Found
Android:
hermesEnabled: true
newArchEnabled: true
iOS:
hermesEnabled: true
newArchEnabled: false

Steps to reproduce

react-native start --reset-cache

Snack, code example, screenshot, or link to a repository

import { AppRegistry, Platform } from 'react-native';
import App from './src/App';
import { name as appName } from './app.json';

// Here, we require "intl", which is used in @lingui/macro, but not available in Hermes (used for Android)
if (Platform.OS === 'android') {
global.Intl = require('intl');
require('intl/locale-data/jsonp/fr.js');
require('intl/locale-data/jsonp/en.js');
// add more locales
}

AppRegistry.registerComponent(appName, () => App);

@cortinico
Copy link

0.72.0-rc.6

What's the reason you're on rc.6 while you should be using 0.72.0?

@cortinico
Copy link

Effectively a duplicate of facebook/react-native#34315

@walidhousni30
Copy link
Author

and there's literally no answer for that tho

@walidhousni30
Copy link
Author

@cortinico i upgraded it to test if there's a fix in the release candidate 6 but no change tho , i dont really know how to solve this issue

@cortinico cortinico transferred this issue from facebook/react-native Jun 28, 2023
@cortinico
Copy link

Moving this over to facebook/metro for furhter investigation as I see metro-transform-worker as part of the stacktrace

@walidhousni30
Copy link
Author

where did you see metro-transform-worker ??

@huntie
Copy link
Member

huntie commented Jun 28, 2023

@walidhousni30 Can you share the contents of your project's metro.config.js file? (Perhaps babelTransformerPath or minifierPath could be unset)

@walidhousni30
Copy link
Author

walidhousni30 commented Jun 28, 2023

@huntie here's the content of metro.config.js

const { getDefaultConfig, mergeConfig } = require('@react-native/metro-config');
const path = require('path');
/**
 * Metro configuration
 * https://facebook.github.io/metro/docs/configuration
 *
 * @type {import('metro-config').MetroConfig}
 */
const config = {
  watchFolders: [path.resolve(__dirname, '../../')],
  transformer: {
    getTransformOptions: async () => ({
      transform: {
        experimentalImportSupport: false,
        inlineRequires: true,
      },
    }),
  },
  resolver: {
    sourceExts: ['js', 'jsx', 'ts', 'tsx', 'mjs'],
    resolverMainFields: ['sbmodern', 'react-native', 'browser', 'main'],
  },
};

module.exports = mergeConfig(getDefaultConfig(__dirname), config);

@huntie
Copy link
Member

huntie commented Jun 28, 2023

From the line numbers reported in the stack trace, it looks like while you're on metro@0.76.5, you have metro-transform-worker 0.71.1 or older installed.

Please can you run the below and share the result here?

yarn why metro-transform-worker

I also note that you are depending on an old version of React Native CLI — React Native 0.72 requires (and depends on) @react-native-community/cli@11.3.2.

npmPackages:
"@react-native-community/cli":
installed: 10.0.0
wanted: 10.0.0

⬆️ Sometimes, this can be caused by installed libraries which (problematically) depend on react-native directly. It could also be from forced dependency versions (e.g. Yarn resolutions — please revert these).

To be sure your dependencies are as specified, try also:

rm -rf node_modules
yarn

@walidhousni30
Copy link
Author

walidhousni30 commented Jun 28, 2023

thank you for your clear and consistent answer @huntie

here's the yarn why metro-transform-worker log

├─ metro@npm:0.70.4
│  └─ metro-transform-worker@npm:0.70.4 (via npm:0.70.4)
│
├─ metro@npm:0.73.10
│  └─ metro-transform-worker@npm:0.73.10 (via npm:0.73.10)
│
└─ metro@npm:0.76.5
   └─ metro-transform-worker@npm:0.76.5 (via npm:0.76.5)

@huntie
Copy link
Member

huntie commented Jun 28, 2023

@walidhousni30 Great — worth digging up why metro@npm:0.70.4 is there (old version), by trying yarn why metro etc. Really, there should only be one version of Metro (metro@npm:0.76.5) in your project.

@walidhousni30
Copy link
Author

walidhousni30 commented Jun 28, 2023

@huntie i did yarn why metro but i dont know exactly how to get rid of the duplicates / old versions

log of yarn why metro

├─ @react-native-community/cli-plugin-metro@npm:11.3.2
│  └─ metro@npm:0.76.5 (via npm:0.76.5)
│
├─ flipper-pkg-lib@npm:0.200.0
│  └─ metro@npm:0.70.4 (via npm:^0.70.2)
│
├─ flipper-server@npm:0.200.0
│  └─ metro@npm:0.70.4 (via npm:^0.70.2)
│
├─ metro-config@npm:0.70.4
│  └─ metro@npm:0.70.4 (via npm:0.70.4)
│
├─ metro-config@npm:0.76.5
│  └─ metro@npm:0.76.5 (via npm:0.76.5)
│
├─ metro-transform-worker@npm:0.70.4
│  └─ metro@npm:0.70.4 (via npm:0.70.4)
│
└─ metro-transform-worker@npm:0.76.5
   └─ metro@npm:0.76.5 (via npm:0.76.5)

@walidhousni30
Copy link
Author

@huntie what do i need to do afterwards , please if you can provide any help ?

@bartolkaruza
Copy link

I had the same issue just now, the solution was removing "metro-config" from "dependencies": {}. (not dev-dependencies)

Screenshot 2023-06-29 at 06 19 41

@huntie
Copy link
Member

huntie commented Jun 29, 2023

@walidhousni30 It looks like flipper-server and flipper-pkg-lib are the dependencies bringing in an older version of Metro. Is this a dependency you can update or eliminate?

Do also try:

  • Removing any explicit metro dependencies or devDependencies in your project's package.json (per @bartolkaruza's fix).
  • As a fallback, using Yarn "resolutions" to force the current version of Metro: 0.76.5.

@walidhousni30
Copy link
Author

@bartolkaruza i have it only on my dev dependency like so
image

i will try huntie method as well so i could force the 0.76.5 metro version

@walidhousni30
Copy link
Author

@huntie MAAAAN ITT WOOOORKS THANK YOU SOOO MUCH
@bartolkaruza your method works as well i cant thank you enough guys

@bartolkaruza
Copy link

bartolkaruza commented Jun 29, 2023

@bartolkaruza i have it only on my dev dependency like so

even if it's in your dev dependencies, it may cause this issue. Try removing it entirely from package.json, then yarn install to clear it from node_modules

@bartolkaruza
Copy link

I commented too soon, glad it's working for you!

@huntie huntie closed this as completed Jun 29, 2023
@walidhousni30
Copy link
Author

I commented too soon, glad it's working for you!

You can imagine i ve spent 2 weeks just trying to find out which module was causing all of this mess after upgrading it

facebook-github-bot pushed a commit that referenced this issue Jul 4, 2023
… paths

Summary:
Issues such as #1017 (and similar previously) have had users running into broken setups due to "multiple versions of Metro" installed.

Ideally, multiple Metros wouldn't be a problem. Metro packages already specify explicit, pinned dependencies on each other, and well-behaved package resolutions should stay within those disconnected graphs of Metro versions.

In particular `metro` already specifies its dependency on `metro-transform-worker`, so it wasn't obvious how we were "escaping" from the correct `metro` and ending up inside the wrong `metro-transform-worker` here. I was able to reproduce #1017 with Berry and debug it.

It turns out that the problem is the use of the (undocumented) `transformer.workerPath` option, which defaults to `'metro/src/DeltaBundler/Worker'`. We pass that to `jest-worker`, which forks a child process `jest-worker/build/workers/processChild`, which resolves the given path *relative to `jest-worker`* - so usually resolves the *hoisted* `metro`, whatever that happens to be.

This fixes the issue by resolving the path from the parent process, within `metro`, and passing an absolute path to `jest-worker`.

Changelog:
```
 - **[Fix]**: Incorrect worker resolution when multiple `metro` versions are installed.
```

Reviewed By: huntie

Differential Revision: D47209874

fbshipit-source-id: 5aa101852e9d33af6f41c118252d9874701a01be
@KareemWilson
Copy link

@walidhousni30 I have the same problem, but I can't solve it :(

@uladzislau-stuk
Copy link

uladzislau-stuk commented Aug 14, 2023

I have just migrated to 72.4 and started getting the same error. Downgrading @react-native/metro-config to 0.72.9 helped me.

With @react-native/metro-config 0.72.11 I get the following error when building the project:

TypeError: The "id" argument must be of type string. Received undefined error index.js: The "id" argument must be of type string. Received undefined

@aanagalli
Copy link

I confirm @uladzislau-stuk comment. Today I created a new project and I was having the same error. Downgrading @react-native/metro-config to 0.72.9 worked fine.

robhogan added a commit to robhogan/react-native that referenced this issue Oct 27, 2023
Summary:
Bump to the latest Metro release. This includes minor breaking changes to Metro subpackages that should *not* be visible to RN users.

Metro release notes: https://github.com/facebook/metro/releases/tag/v0.80.0

## Moving to unpinned versioning
Metro is a multi-package project, and not pinning to an exact version means multiple versions of `metro*` packages may appear in an RN project.

This isn't unusual in the NPM ecosystem and *shouldn't* be a problem, but historically has caused issues (eg facebook#34714, facebook/metro#1017). The root cause of all of these issues, as far as we know, was fixed in facebook/metro@6d46078, a bug where Node hierarchical resolution was effectively sidestepped via a relative worker path, resulting in a mismatch between transformer and host process.

In addition, the fact that `react-refresh`, `metro-react-native-babel-transformer` and `metro-react-native-babel-preset` are now fully moved into the `react-native/` scope and versioned with React Native means there are no circular dependencies between React Native and Metro, explicit or implicit, and we're much more clearly decoupled.

So, we're moving to caret versioning to allow React Native users to pick up Metro fixes and features without requiring React Native releases and user upgrades.

Changelog:
[General][Changed] - Update Metro to ^v0.80.0, stop pinning to an exact version

Differential Revision: D50731999
robhogan added a commit to robhogan/react-native that referenced this issue Oct 27, 2023
Summary:

Bump to the latest Metro release. This includes minor breaking changes to Metro subpackages that should *not* be visible to RN users.

Metro release notes: https://github.com/facebook/metro/releases/tag/v0.80.0

## Moving to unpinned versioning
Metro is a multi-package project, and not pinning to an exact version means multiple versions of `metro*` packages may appear in an RN project.

This isn't unusual in the NPM ecosystem and *shouldn't* be a problem, but historically has caused issues (eg facebook#34714, facebook/metro#1017). The root cause of all of these issues, as far as we know, was fixed in facebook/metro@6d46078, a bug where Node hierarchical resolution was effectively sidestepped via a relative worker path, resulting in a mismatch between transformer and host process.

In addition, the fact that `react-refresh`, `metro-react-native-babel-transformer` and `metro-react-native-babel-preset` are now fully moved into the `react-native/` scope and versioned with React Native means there are no circular dependencies between React Native and Metro, explicit or implicit, and we're much more clearly decoupled.

So, we're moving to caret versioning to allow React Native users to pick up Metro fixes and features without requiring React Native releases and user upgrades.

Changelog:
[General][Changed] - Update Metro to ^v0.80.0, stop pinning to an exact version

Reviewed By: GijsWeterings

Differential Revision: D50731999
facebook-github-bot pushed a commit to facebook/react-native that referenced this issue Oct 27, 2023
Summary:
Pull Request resolved: #41219

Bump to the latest Metro release. This includes minor breaking changes to Metro subpackages that should *not* be visible to RN users.

Metro release notes: https://github.com/facebook/metro/releases/tag/v0.80.0

## Moving to unpinned versioning
Metro is a multi-package project, and not pinning to an exact version means multiple versions of `metro*` packages may appear in an RN project.

This isn't unusual in the NPM ecosystem and *shouldn't* be a problem, but historically has caused issues (eg #34714, facebook/metro#1017). The root cause of all of these issues, as far as we know, was fixed in facebook/metro@6d46078, a bug where Node hierarchical resolution was effectively sidestepped via a relative worker path, resulting in a mismatch between transformer and host process.

In addition, the fact that `react-refresh`, `metro-react-native-babel-transformer` and `metro-react-native-babel-preset` are now fully moved into the `react-native/` scope and versioned with React Native means there are no circular dependencies between React Native and Metro, explicit or implicit, and we're much more clearly decoupled.

So, we're moving to caret versioning to allow React Native users to pick up Metro fixes and features without requiring React Native releases and user upgrades.

Changelog:
[General][Changed] - Update Metro to ^v0.80.0, stop pinning to an exact version

Reviewed By: GijsWeterings

Differential Revision: D50731999

fbshipit-source-id: 57b07bf73c0b31f392c4d36376ca48b48a8bd598
Othinn pushed a commit to Othinn/react-native that referenced this issue Oct 30, 2023
Summary:
Pull Request resolved: facebook#41219

Bump to the latest Metro release. This includes minor breaking changes to Metro subpackages that should *not* be visible to RN users.

Metro release notes: https://github.com/facebook/metro/releases/tag/v0.80.0

## Moving to unpinned versioning
Metro is a multi-package project, and not pinning to an exact version means multiple versions of `metro*` packages may appear in an RN project.

This isn't unusual in the NPM ecosystem and *shouldn't* be a problem, but historically has caused issues (eg facebook#34714, facebook/metro#1017). The root cause of all of these issues, as far as we know, was fixed in facebook/metro@6d46078, a bug where Node hierarchical resolution was effectively sidestepped via a relative worker path, resulting in a mismatch between transformer and host process.

In addition, the fact that `react-refresh`, `metro-react-native-babel-transformer` and `metro-react-native-babel-preset` are now fully moved into the `react-native/` scope and versioned with React Native means there are no circular dependencies between React Native and Metro, explicit or implicit, and we're much more clearly decoupled.

So, we're moving to caret versioning to allow React Native users to pick up Metro fixes and features without requiring React Native releases and user upgrades.

Changelog:
[General][Changed] - Update Metro to ^v0.80.0, stop pinning to an exact version

Reviewed By: GijsWeterings

Differential Revision: D50731999

fbshipit-source-id: 57b07bf73c0b31f392c4d36376ca48b48a8bd598
@CaptainJeff
Copy link

Removing metro-config fixed it for me too

@meraezekiel
Copy link

Thank you so much ! i just copy the added packages (color green) aside from "react-native-windows" , it works ! . This is the link below where i follow the solution

lovegaoshi/azusa-player-mobile@84a779f

robhogan added a commit that referenced this issue Jan 29, 2024
… paths

Summary:
Issues such as #1017 (and similar previously) have had users running into broken setups due to "multiple versions of Metro" installed.

Ideally, multiple Metros wouldn't be a problem. Metro packages already specify explicit, pinned dependencies on each other, and well-behaved package resolutions should stay within those disconnected graphs of Metro versions.

In particular `metro` already specifies its dependency on `metro-transform-worker`, so it wasn't obvious how we were "escaping" from the correct `metro` and ending up inside the wrong `metro-transform-worker` here. I was able to reproduce #1017 with Berry and debug it.

It turns out that the problem is the use of the (undocumented) `transformer.workerPath` option, which defaults to `'metro/src/DeltaBundler/Worker'`. We pass that to `jest-worker`, which forks a child process `jest-worker/build/workers/processChild`, which resolves the given path *relative to `jest-worker`* - so usually resolves the *hoisted* `metro`, whatever that happens to be.

This fixes the issue by resolving the path from the parent process, within `metro`, and passing an absolute path to `jest-worker`.

Changelog:
```
 - **[Fix]**: Incorrect worker resolution when multiple `metro` versions are installed.
```

Reviewed By: huntie

Differential Revision: D47209874

fbshipit-source-id: 5aa101852e9d33af6f41c118252d9874701a01be
robhogan added a commit that referenced this issue Jan 30, 2024
… paths

Summary:
Issues such as #1017 (and similar previously) have had users running into broken setups due to "multiple versions of Metro" installed.

Ideally, multiple Metros wouldn't be a problem. Metro packages already specify explicit, pinned dependencies on each other, and well-behaved package resolutions should stay within those disconnected graphs of Metro versions.

In particular `metro` already specifies its dependency on `metro-transform-worker`, so it wasn't obvious how we were "escaping" from the correct `metro` and ending up inside the wrong `metro-transform-worker` here. I was able to reproduce #1017 with Berry and debug it.

It turns out that the problem is the use of the (undocumented) `transformer.workerPath` option, which defaults to `'metro/src/DeltaBundler/Worker'`. We pass that to `jest-worker`, which forks a child process `jest-worker/build/workers/processChild`, which resolves the given path *relative to `jest-worker`* - so usually resolves the *hoisted* `metro`, whatever that happens to be.

This fixes the issue by resolving the path from the parent process, within `metro`, and passing an absolute path to `jest-worker`.

Changelog:
```
 - **[Fix]**: Incorrect worker resolution when multiple `metro` versions are installed.
```

Reviewed By: huntie

Differential Revision: D47209874

fbshipit-source-id: 5aa101852e9d33af6f41c118252d9874701a01be
@benohiit
Copy link

npm install @react-native/metro-config@0.72.9 --dev worked for me on android, but not on ios until I updated npm install @react-native-community/cli@11.3.2 --dev thanks @huntie

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants