Refactor argument execution in with-environment.sh to support multipl…

[vishalvadodariya]

Resolving #54140

Summary:

Fixed argument passing issue in with-environment.sh script that prevented passing arguments to subcommands in iOS builds. The script was only executing the first argument ("$1") instead of all provided arguments ("$@"), causing build failures when users tried to pass custom entry file arguments to react-native-xcode.sh.

Problem: Users could not pass arguments like index.ts to the React Native bundling script through with-environment.sh, resulting in "No such file or directory" errors during iOS builds.

Solution: Changed line 46 in with-environment.sh from "$1" to "$@" to properly pass all arguments to the subcommand.

Changelog:

[IOS] [FIXED] - Fixed argument passing in with-environment.sh script to support passing arguments to subcommands

Test Plan:

1. Created test script to verify argument passing functionality
2. Tested the fix by running:

   ./with-environment.sh /tmp/test_script.sh index.ts

3. Verified output shows the test script correctly receives the index.ts argument:
4. Test script receivrd compatibility - existing usage without arguments continues to work
5. No linting errors introduced by the change

The fix resolves the issue described in #54140 where users cannot pass custom entry file arguments to the React Native bundling process in iOS builds.

Files Changed:

• packages/react-native/scripts/xcode/with-environment.sh - Updated line 46 to use "$@" instead of "$1"

Breaking Changes:

None - this change maintains full backward compatibility.

Additional Notes:

This is a minimal, safe fix that addresses the exact issue reported in the GitHub issue. The change allows users to pass custom entry file arguments to the React Native bundling process, which is essential for projects that use non-standard entry points.

[meta-cla]

Hi @vishalvadodariya!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[meta-codesync]

@andrewdacenko has imported this pull request. If you are a Meta employee, you can view this in D84637163.

[cortinico]

Review automatically exported from Phabricator review in Meta.

[vishalvadodariya]

Hi @cortinico 👋
I see that the PR mentions “Requested changes must be addressed to merge this pull request” but I don’t see any specific review comments on GitHub.
Could you please clarify what changes are needed or share any feedback from the internal Phabricator review?
I’ll be happy to update the PR accordingly.
Thanks!

[cortinico]

Hi @cortinico 👋 I see that the PR mentions “Requested changes must be addressed to merge this pull request” but I don’t see any specific review comments on GitHub. Could you please clarify what changes are needed or share any feedback from the internal Phabricator review? I’ll be happy to update the PR accordingly. Thanks!

Could you clarify what's your use case @vishalvadodariya ? Why do you need this change now?

[vishalvadodariya]

Hi @cortinico ,

I have raised PR to resolve the Issue #54140.