not-react-native-macos 0.87.1-rc.1 → 0.87.1-rc.2

package/macos/metro-config.js

@@ -36,36 +36,49 @@
 
 'use strict';
 
-const MACOS_SUFFIX = /\.macos\.[^.]+$/;
-
 /**
- * Resolve one specifier as `.macos.*` -> iOS resolution.
+ * Resolve one specifier for the `macos` platform.
+ *
+ * Metro's own `macos` resolution already does the right thing almost always:
+ * `Foo.macos.js`, then `Foo.native.js`, then the shared `Foo.js`. A package that
+ * ships `Foo.ios`, `Foo.android` *and* `Foo.js` means the shared file for every
+ * other platform, macOS included -- expo-router's `toolbar/native.tsx` is
+ * exactly that, and taking its `.ios` sibling instead drags in iOS-only native
+ * modules that are not linked here.
+ *
+ * Falling back to iOS is still needed twice:
  *
- * Only a file that genuinely carries the `.macos.` suffix counts as an
- * override. Anything else is the shared file, which iOS resolution reaches too
- * -- and which may itself be the re-export that needs a suffixed sibling.
+ *   - Nothing resolves at all, because the module exists only as `Foo.ios.js`
+ *     and `Foo.android.js`. ReactDevToolsSettingsManager is one of about twenty.
+ *   - The shared file *is* the importer. `Platform.js` re-exports `./Platform`
+ *     and expects a platform-suffixed sibling to answer; with no
+ *     `Platform.macos.js` it resolves to itself, and `Platform.OS` comes out
+ *     undefined by way of a require cycle.
+ *
+ * So: take Metro's answer unless it is unusable, and only then ask for iOS.
  */
-function resolveMacOS(context, moduleName, platform) {
+function resolveMacOS(context, moduleName, platform, next) {
+  const resolve = next ?? ((ctx, name, plat) => ctx.resolveRequest(ctx, name, plat));
+
   if (platform !== 'macos') {
-    return context.resolveRequest(context, moduleName, platform);
+    return resolve(context, moduleName, platform);
   }
 
   const attempt = candidate => {
     try {
-      return context.resolveRequest(context, moduleName, candidate);
+      return resolve(context, moduleName, candidate);
     } catch (error) {
       return error;
     }
   };
 
   const macos = attempt('macos');
-  if (
-    macos != null &&
-    !(macos instanceof Error) &&
-    typeof macos.filePath === 'string' &&
-    MACOS_SUFFIX.test(macos.filePath)
-  ) {
-    return macos;
+  if (!(macos instanceof Error)) {
+    const resolvedToImporter =
+      typeof macos.filePath === 'string' && macos.filePath === context.originModulePath;
+    if (!resolvedToImporter) {
+      return macos;
+    }
   }
 
   const ios = attempt('ios');
@@ -73,24 +86,33 @@ function resolveMacOS(context, moduleName, platform) {
     return ios;
   }
 
-  // Report the macOS failure, not the iOS one: it names the platform asked for.
-  if (macos instanceof Error) {
-    throw macos;
-  }
-  return macos;
+  // Report the macOS failure: it names the platform that was asked for.
+  throw macos instanceof Error ? macos : ios;
 }
 
 /**
  * A Metro config fragment that teaches the resolver about macOS.
  *
- * Merge it over `getDefaultConfig()`. It sets nothing else, so an app keeps
- * full control of transformer, serializer and watch folders.
+ * Pass the config you are extending. If it already has a `resolveRequest` --
+ * `@expo/metro-config` installs a substantial one -- this *wraps* it rather
+ * than replacing it, because `context.resolveRequest` inside a custom resolver
+ * is Metro's default resolver, not whatever was configured before. Assigning
+ * over it silently drops the other resolver's behaviour.
+ *
+ * Sets nothing else, so an app keeps full control of transformer, serializer
+ * and watch folders.
+ *
+ *   const config = getDefaultConfig(__dirname);
+ *   module.exports = mergeConfig(config, getMacOSConfig(config));
  */
-function getMacOSConfig() {
+function getMacOSConfig(baseConfig) {
+  const upstream = baseConfig?.resolver?.resolveRequest;
+
   return {
     resolver: {
       platforms: ['macos', 'ios', 'android', 'native'],
-      resolveRequest: resolveMacOS,
+      resolveRequest: (context, moduleName, platform) =>
+        resolveMacOS(context, moduleName, platform, upstream),
     },
   };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "not-react-native-macos",
-  "version": "0.87.1-rc.1",
+  "version": "0.87.1-rc.2",
   "description": "A framework for building native apps using React",
   "license": "MIT",
   "repository": {

package/scripts/cocoapods/autolinking.rb

@@ -38,7 +38,16 @@ def list_native_modules!(config_command)
   config = JSON.parse(json)
 
   packages = config["dependencies"]
-  ios_project_root = Pathname.new(config["project"]["ios"]["sourceDir"])
+
+  # [macOS] The autolinking JSON is keyed by platform, and a macOS build asks the
+  # CLI for `--platform macos`, so the only key present is "macos" -- indexing
+  # "ios" unconditionally crashes with `undefined method '[]' for nil`. Take the
+  # key from the target's own platform, and fall back to "ios" so nothing changes
+  # for an iOS build. macOS]
+  autolinking_platform = current_target_definition&.platform&.name == :osx ? "macos" : "ios"
+
+  project_config = config["project"][autolinking_platform] || config["project"]["ios"]
+  ios_project_root = Pathname.new(project_config["sourceDir"])
   react_native_path = Pathname.new(config["reactNativePath"])
   codegen_output_path = ios_project_root.join("build/generated/autolinking/autolinking.json")
 
@@ -49,7 +58,7 @@ def list_native_modules!(config_command)
   found_pods = []
 
   packages.each do |package_name, package|
-    next unless package_config = package["platforms"]["ios"]
+    next unless package_config = package["platforms"][autolinking_platform] # [macOS] was hardcoded "ios"
 
     name = package["name"]
     podspec_path = package_config["podspecPath"]

package/scripts/cocoapods/codegen.rb

@@ -34,7 +34,9 @@ def run_codegen!(
     :config_file_dir => config_file_dir,
     :codegen_output_dir => codegen_output_dir,
     :config_key => config_key,
-    :folly_version => folly_version
+    :folly_version => folly_version,
+    # [macOS] see CodegenUtils#use_react_native_codegen_discovery!
+    :target_platform => (current_target_definition&.platform&.name == :osx ? "macos" : "ios")
   )
 end
 

package/scripts/cocoapods/codegen_utils.rb

@@ -35,7 +35,12 @@ class CodegenUtils
       folly_version: Helpers::Constants.folly_config[:version],
       codegen_utils: CodegenUtils.new(),
       file_manager: File,
-      logger: CodegenUtils::UI
+      logger: CodegenUtils::UI,
+      # [macOS] The generated providers are platform-specific: they map names to
+      # classes that only exist if the owning library was built for this
+      # platform. Upstream hardcodes "ios" because every library supports iOS.
+      # macOS]
+      target_platform: "ios"
       )
       return if codegen_disabled
 
@@ -58,7 +63,7 @@ class CodegenUtils
           "#{relative_installation_root}/#{react_native_path}/scripts/generate-codegen-artifacts.js",
           "-p", "#{app_path}",
           "-o", Pod::Config.instance.installation_root,
-          "-t", "ios",
+          "-t", target_platform, # [macOS] was hardcoded "ios"
         ])
       Pod::UI.puts out;
 

package/scripts/codegen/generate-artifacts-executor/generateRCTThirdPartyComponents.js

@@ -139,7 +139,9 @@ function generateRCTThirdPartyComponents(
     .flatMap(library => {
       const components = componentsInLibraries[library];
       return components.map(({componentName, className}) => {
-        return `\t\t@"${componentName}": NSClassFromString(@"${className}"), // ${library}`;
+        // [macOS] The class name, not NSClassFromString: the provider resolves
+        // it at runtime and skips what is not in the binary. See the template.
+        return `\t\t@"${componentName}": @"${className}", // ${library}`;
       });
     })
     .join('\n');

package/scripts/codegen/generate-artifacts-executor/index.js

@@ -28,7 +28,10 @@ const {
   generateRCTThirdPartyComponents,
 } = require('./generateRCTThirdPartyComponents');
 const {generateReactCodegenPodspec} = require('./generateReactCodegenPodspec');
-const {generateSchemaInfos} = require('./generateSchemaInfos');
+const {
+  extractSupportedApplePlatforms, // [macOS] filters the Apple providers by platform
+  generateSchemaInfos,
+} = require('./generateSchemaInfos');
 const {
   generateUnstableModulesRequiringMainQueueSetupProvider,
 } = require('./generateUnstableModulesRequiringMainQueueSetupProvider');
@@ -39,6 +42,7 @@ const {
   findCodegenEnabledLibraries,
   findDisabledLibrariesByPlatform,
   findReactNativeRootPath,
+  isReactNativeCoreLibrary, // [macOS] core libraries skip the platform filter
   pkgJsonIncludesGeneratedCode,
   readPkgJsonInDirectory,
   readReactNativeConfig,
@@ -72,6 +76,18 @@ function execute(
     codegenLog(`Analyzing ${path.join(projectRoot, 'package.json')}`);
 
     const supportedPlatforms = ['android', 'ios'];
+
+    // [macOS] macOS consumes the iOS codegen output -- same specs, same output
+    // directory, same native code. The only thing that differs is which
+    // libraries may appear in the generated Apple providers, because a library
+    // that does not support macOS is never compiled and its class would be nil.
+    // So normalise the target here and keep the real platform for that filter.
+    const applePlatform = targetPlatform === 'macos' ? 'macos' : null;
+    if (applePlatform != null) {
+      targetPlatform = 'ios';
+    }
+    // macOS]
+
     if (
       targetPlatform !== 'all' &&
       !supportedPlatforms.includes(targetPlatform)
@@ -152,15 +168,47 @@ function execute(
       }
 
       if (source === 'app' && platform !== 'android') {
+        // [macOS] Only libraries that support the platform being built.
+        //
+        // The generated providers map component and module names to classes via
+        // NSClassFromString, and put the result straight into a dictionary
+        // literal. A library whose podspec does not support this platform is
+        // never compiled, so its class is nil, and the dictionary throws
+        // "attempt to insert nil object from objects[0]" as the app starts.
+        //
+        // Every library supports iOS, so upstream never had to filter. An
+        // out-of-tree platform does: on macOS an app pulls in plenty of
+        // iOS-only modules through its dependency tree. macOS]
+        const applePlatformLibraries = libraries.filter(library => {
+          if (isReactNativeCoreLibrary(library.config.name)) {
+            return true;
+          }
+          let supported;
+          try {
+            supported = extractSupportedApplePlatforms(
+              library.config.name,
+              library.libraryPath,
+            );
+          } catch {
+            supported = null;
+          }
+          // No podspec, or one that says nothing, means no opinion. Keep the
+          // library, which is what upstream did for every platform.
+          return supported == null || supported[applePlatform ?? platform] !== false;
+        });
+
         // These components are only required by apps, not by libraries and are Apple specific.
-        generateRCTThirdPartyComponents(libraries, reactCodegenOutputPath);
+        generateRCTThirdPartyComponents(
+          applePlatformLibraries,
+          reactCodegenOutputPath,
+        );
         generateRCTModuleProviders(
           projectRoot,
           pkgJson,
-          libraries,
+          applePlatformLibraries,
           reactCodegenOutputPath,
         );
-        generateCustomURLHandlers(libraries, reactCodegenOutputPath);
+        generateCustomURLHandlers(applePlatformLibraries, reactCodegenOutputPath);
         generateUnstableModulesRequiringMainQueueSetupProvider(
           libraries,
           reactCodegenOutputPath,

package/scripts/codegen/templates/RCTThirdPartyComponentsProviderMM.template

@@ -19,9 +19,30 @@
   static dispatch_once_t nativeComponentsToken;
 
   dispatch_once(&nativeComponentsToken, ^{
-    thirdPartyComponents = @{
+    // [macOS] Built key by key, skipping classes that are not in the binary.
+    //
+    // The entries below are class *names*, resolved one at a time. A literal of
+    // NSClassFromString results throws "attempt to insert nil object" the moment
+    // one misses. On iOS none ever do. On an out-of-tree platform they do: the
+    // dependency tree holds libraries that are not built for it, and codegen
+    // cannot always tell -- a podspec may advertise a platform that autolinking
+    // then skips.
+    //
+    // A component that is not linked cannot be rendered either way. Leaving it
+    // out of the map lets the rest of the app start. macOS]
+    NSDictionary<NSString *, NSString *> *candidates = @{
 {thirdPartyComponentsMapping}
     };
+
+    NSMutableDictionary<NSString *, Class<RCTComponentViewProtocol>> *resolved =
+        [NSMutableDictionary dictionaryWithCapacity:candidates.count];
+    for (NSString *name in candidates) {
+      Class componentClass = NSClassFromString(candidates[name]);
+      if (componentClass != nil) {
+        resolved[name] = componentClass;
+      }
+    }
+    thirdPartyComponents = [resolved copy];
   });
 
   return thirdPartyComponents;

package/src/private/devsupport/rndevtools/ReactDevToolsSettingsManager.macos.js

@@ -0,0 +1,17 @@
+/*
+ * Copyright (c) Meta Platforms, Inc. and affiliates.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ *
+ * @flow strict-local
+ * @format
+ */
+
+// [macOS] macOS resolves as `.macos` -> `.native` -> shared, so without this
+// file `ReactDevToolsSettingsManager` re-exports itself: the shared file is a
+// stub that expects a platform-suffixed sibling to answer. Point it at the iOS
+// implementation, which is what this fork uses on macOS wherever upstream has
+// no platform-neutral one. macOS]
+
+export * from './ReactDevToolsSettingsManager.ios';