-
Notifications
You must be signed in to change notification settings - Fork 619
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
Comments
What's the reason you're on rc.6 while you should be using |
Effectively a duplicate of facebook/react-native#34315 |
and there's literally no answer for that tho |
@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 |
Moving this over to facebook/metro for furhter investigation as I see |
where did you see metro-transform-worker ?? |
@walidhousni30 Can you share the contents of your project's |
@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); |
From the line numbers reported in the stack trace, it looks like while you're on 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)
⬆️ Sometimes, this can be caused by installed libraries which (problematically) depend on To be sure your dependencies are as specified, try also: rm -rf node_modules
yarn |
thank you for your clear and consistent answer @huntie here's the yarn why metro-transform-worker log
|
@walidhousni30 Great — worth digging up why |
@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
|
@huntie what do i need to do afterwards , please if you can provide any help ? |
@walidhousni30 It looks like Do also try:
|
@bartolkaruza i have it only on my dev dependency like so i will try huntie method as well so i could force the 0.76.5 metro version |
@huntie MAAAAN ITT WOOOORKS THANK YOU SOOO MUCH |
even if it's in your dev dependencies, it may cause this issue. Try removing it entirely from package.json, then |
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 |
… 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
@walidhousni30 I have the same problem, but I can't solve it :( |
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:
|
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. |
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
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
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
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
Removing metro-config fixed it for me too |
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 |
… 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
… 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
|
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 .
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);
The text was updated successfully, but these errors were encountered: