Skip to content

Conversation

@alloy
Copy link
Member

@alloy alloy commented Apr 22, 2020

Summary:

These changes make it so react-native-macos apps can use the native_modules.rb script as-is, but only activate pods in those targets that target the platform the pods support.

For instance, consider these npm packages that come with native modules:

  • ios-dep
  • macos-dep
  • ios-and-macos-dep

…and given a Podfile like the following:

require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'

abstract_target 'Shared' do
  pod 'React', :path => "../node_modules/react-native-macos/"
  # ...

  target 'A iOS Target' do
    platform :ios, '9'
    use_native_modules!
  end

  target 'A macOS Target' do
    platform :macos, '10.14'
    use_native_modules!
  end
end

…the result would be that:

  • A iOS Target has the following dependencies:
    • ios-dep
    • ios-and-macos-dep
  • A macOS Target has the following dependencies:
    • macos-dep
    • ios-and-macos-dep

NOTE: In a future major version, the native_modules support will likely move to a cli-platform-apple package, but for now this was the least invasive change.

Test Plan:

Changes have full test coverage, which have been moved from Ruby to JS, and I’ve performed test runs with new applications.

* @property commands - An array of commands that are present in 3rd party packages
*/
export type Config = {
export interface Config extends IOSNativeModulesConfig {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is done purely to ensure the Config doesn’t deviate in a way that the otherwise uncheckable Ruby source.

* have the name of the package. This property will be
* removed in a future major version.
*
* @todo Log a warning when this is used.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have to follow-up on this in a future iteration.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll need to identify libraries that follow a pattern of adding a Podspec into ios/ dir and send PRs.

* only make changes to this interface (or `IOSScriptPhase`) if the data
* requirements of `native_modules.rb` change.
*/
export interface IOSNativeModulesConfig {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❗ So this should only change if the Ruby source changes and should not be refactored/shared with other typings, even if they are similar.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is that? Wouldn't it be better to just reference

export interface Config extends IOSNativeModulesConfig {
root: string;
reactNativePath: string;
project: ProjectConfig;
assets: string[];
dependencies: {[key: string]: Dependency};
platforms: {
android: PlatformConfig<
AndroidProjectConfig,
AndroidProjectParams,
AndroidDependencyConfig,
AndroidDependencyParams
>;
ios: PlatformConfig<
IOSProjectConfig,
IOSProjectParams,
IOSDependencyConfig,
IOSDependencyParams
>;
[name: string]: PlatformConfig<any, any, any, any>;
};
commands: Command[];
}
directly? This is the exact type of the JSON output from the command.

Could you help me understand where and how it is used? Maybe it's not the right place for it then (in shared package), but next to a utility?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because TS cannot type-check the Ruby code, so people making changes to this Config interface might accidentally break some input data assumption made by it. Put differently, you should see this interface as if it were the function signature declaration of the Ruby code, if it were written in TS.

Only include pods in targets that target platforms the pod supports.
@alloy alloy force-pushed the add-macos-autolinking-to-cli-platform-ios branch from 85040b6 to 9ef86dd Compare April 22, 2020 16:26

# Skip pods that do not support the platform of the current target.
if platform = current_target_definition.platform
next unless spec.supported_on_platform?(platform.name)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the actual semantic change of the PR, so tiny 😂

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for that comment! And also, I am impressed by the CocoaPods API :D

use_native_modules!(config)
end
require "json"
runInput = JSON.parse(ARGF.read)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Ruby script receives a JSON payload via stdin

end
unless runInput["capture_stdout"]
puts podfile.to_hash.to_json
end
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

…and spits out a serialised version of the Podfile to stdout.

- run-lint
cocoa-pods:
unit-tests:
executor: noderuby
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we know which version of Node is run on this image? Would be cool if it was the latest or so

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn’t spot an explicit listing of the version in the CI output, but it’s using circleci/ruby:2.4-node and in this listing I see ENV NODE_VERSION=12.16.2. So probably that?

@alloy
Copy link
Member Author

alloy commented Apr 22, 2020

Seeing as it’s failing on the lts-tests, and also not to make things too hard on collaborators, I’ll add a check and disable the tests in case the env doesn’t support ruby/cocoapods.

@alloy alloy force-pushed the add-macos-autolinking-to-cli-platform-ios branch from e5382db to 1a411b3 Compare April 22, 2020 17:57
Copy link
Member

@grabbou grabbou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like the changes. Good job! Just not sure about typings itself, rather than that, let's ship it!

@alloy
Copy link
Member Author

alloy commented May 27, 2020

Ace, thanks for the review! I feel confident about the need for the typing, but if needed we can amend the wording in the comment to clarify in a follow-up PR, so I’ll go ahead and merge for now 👍

@alloy alloy merged commit 0a93be1 into react-native-community:master May 27, 2020
@alloy alloy deleted the add-macos-autolinking-to-cli-platform-ios branch May 27, 2020 10:06
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

Successfully merging this pull request may close these issues.

3 participants