-
Notifications
You must be signed in to change notification settings - Fork 99
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
rnx-bundle runs the metro Server without "watch:false" #2332
Comments
Is this all we need to do? diff --git a/packages/metro-service/src/bundle.ts b/packages/metro-service/src/bundle.ts
index fc994559..82b7f947 100644
--- a/packages/metro-service/src/bundle.ts
+++ b/packages/metro-service/src/bundle.ts
@@ -87,7 +87,7 @@ export async function bundle(
platform: args.platform,
unstable_transformProfile: args.unstableTransformProfile,
};
- const server = new Server(config);
+ const server = new Server(config, { watch: false });
try {
const bundle = await output.build(server, requestOpts); |
On closer inspection, So I'm not sure this is always correct. Maybe this makes sense when you're on CI? Need to check whether the watcher persists. |
The only thing I can think of is that in the case of a watchman watcher, it probably launches watchman, which would persist. The node watcher, and the node part of the watchman watcher I dont think persists. |
I think this probably should be fixed in the community cli too. |
I think locally, this makes sense. People can reuse the instance if they need to run bundle again, or switch between dev server and using bundles (I know I do this a lot). Turning it off seems wrong. I've also been told that either CLI or Metro automatically disable watching when it detects it is on CI, so we shouldn't have to do anything here. |
The command ends up either in @react-native-community/cli-plugin-metro buildBundleWithConfig or in @rnx-kit/metro-service calling new Server(config).
When doing a single bundle command it should use new Server(config, {watch:false}) to prevent the extra work of spinning up the jest-haste-map file watcher.
The text was updated successfully, but these errors were encountered: