search

customerio / customerio-expo-plugin

MIT License
11 stars 9 forks source link

fix!: auto-update native SDK and easier rich push install #81

Closed levibostian closed 1 year ago

levibostian commented 1 year ago

Makes the Expo plugin compatible with upcoming RN SDK version 3.0 introduced by this pr.

Part of ticket: https://github.com/customerio/issues/issues/10356

Breaking change

This PR is not backwards compatible with previous Expo plugin versions and will require customers call expo prebuild --clean to introduce these changes to their code.

This PR introduces comment headers in the Podfile:

target 'testiosapp' do
  ...
# --- CustomerIO Host App START ---
  ...
# --- CustomerIO Host App END ---
  ...
end

as an idea to no longer need to ask customers to run --clean but they can run just prebuild and our plugin will make modifications to the existing Podfile.

Dependencies

Generated Podfile after prebuild:

require File.join(File.dirname(`node --print 
"require.resolve('expo/package.json')"`), "scripts/autolinking")
require File.join(File.dirname(`node --print 
"require.resolve('react-native/package.json')"`), "scripts/react_native_pods")
require File.join(File.dirname(`node --print 
"require.resolve('@react-native-community/cli-platform-ios/package.json')"`), 
"native_modules")

require 'json'
podfile_properties = JSON.parse(File.read(File.join(__dir__, 
'Podfile.properties.json'))) rescue {}

ENV['RCT_NEW_ARCH_ENABLED'] = podfile_properties['newArchEnabled'] == 'true' ? 
'1' : '0'
ENV['EX_DEV_CLIENT_NETWORK_INSPECTOR'] = '1' if 
podfile_properties['EX_DEV_CLIENT_NETWORK_INSPECTOR'] == 'true'

platform :ios, podfile_properties['ios.deploymentTarget'] || '13.0'
install! 'cocoapods',
  :deterministic_uuids => false

prepare_react_native_project!

# If you are using a `react-native-flipper` your iOS build will fail when 
`NO_FLIPPER=1` is set.
# because `react-native-flipper` depends on (FlipperKit,...), which will be 
excluded. To fix this,
# you can also exclude `react-native-flipper` in `react-native.config.js`
#
# ```js
# module.exports = {
#   dependencies: {
#     ...(process.env.NO_FLIPPER ? { 'react-native-flipper': { platforms: { ios: 
null } } } : {}),
#   }
# }
# ```
flipper_config = FlipperConfiguration.disabled
if ENV['NO_FLIPPER'] == '1' then
  # Explicitly disabled through environment variables
  flipper_config = FlipperConfiguration.disabled
elsif podfile_properties.key?('ios.flipper') then
  # Configure Flipper in Podfile.properties.json
  if podfile_properties['ios.flipper'] == 'true' then
    flipper_config = FlipperConfiguration.enabled(["Debug", "Release"])
  elsif podfile_properties['ios.flipper'] != 'false' then
    flipper_config = FlipperConfiguration.enabled(["Debug", "Release"], { 
'Flipper' => podfile_properties['ios.flipper'] })
  end
end

target 'testiosapp' do
  use_expo_modules!
  config = use_native_modules!

  use_frameworks! :linkage => podfile_properties['ios.useFrameworks'].to_sym if 
podfile_properties['ios.useFrameworks']
  use_frameworks! :linkage => ENV['USE_FRAMEWORKS'].to_sym if 
ENV['USE_FRAMEWORKS']

  # Flags change depending on the env values.
  flags = get_default_flags()

  use_react_native!(
    :path => config[:reactNativePath],
    :hermes_enabled => podfile_properties['expo.jsEngine'] == nil || 
podfile_properties['expo.jsEngine'] == 'hermes',
    :fabric_enabled => flags[:fabric_enabled],
    # An absolute path to your application root.
    :app_path => "#{Pod::Config.instance.installation_root}/..",
    # Note that if you have use_frameworks! enabled, Flipper will not work if 
enabled
    :flipper_configuration => flipper_config
  )
# --- CustomerIO Host App START ---
  pod 'customerio-reactnative/apn', :path => 
'../node_modules/customerio-reactnative'
# --- CustomerIO Host App END ---

  post_install do |installer|
    react_native_post_install(
      installer,
      config[:reactNativePath],
      # Set `mac_catalyst_enabled` to `true` in order to apply patches
      # necessary for Mac Catalyst builds
      :mac_catalyst_enabled => false
    )
    __apply_Xcode_12_5_M1_post_install_workaround(installer)

    # This is necessary for Xcode 14, because it signs resource bundles by 
default
    # when building for devices.
    installer.target_installation_results.pod_target_installation_results
      .each do |pod_name, target_installation_result|
      target_installation_result.resource_bundle_targets.each do 
|resource_bundle_target|
        resource_bundle_target.build_configurations.each do |config|
          config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
        end
      end
    end
  end

  post_integrate do |installer|
    begin
      expo_patch_react_imports!(installer)
    rescue => e
      Pod::UI.warn e
    end
  end
end
# --- CustomerIO Notification START ---
target 'NotificationService' do
  use_frameworks! :linkage => :static
  pod 'customerio-reactnative-richpush/apn', :path => 
'../node_modules/customerio-reactnative'
end
# --- CustomerIO Notification END ---
github-actions[bot] commented 1 year ago

Pull request title looks good 👍!

If this pull request gets merged, it will cause a new release of the software. Example: If this project's latest release version is 1.0.0. If this pull request gets merged in, the next release of this project will be 2.0.0. This pull request is a breaking change.

All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...
This project uses a special format for pull requests titles. Don't worry, it's easy! This pull request title should be in this format: ``` : short description of change being made ``` **If your pull request [introduces breaking changes](https://web.archive.org/web/20220725195319/https://nordicapis.com/what-are-breaking-changes-and-how-do-you-avoid-them/)** to the code, use this format: ``` !: short description of breaking change ``` where `` is one of the following: - `feat:` - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project. - `fix:` - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project. - `docs:` - This pull request is making documentation changes, only. - `refactor:` - A change was made that doesn't fix a bug or add a feature. - `test:` - Adds missing tests or fixes broken tests. - `style:` - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc) - `perf:` - Changes improve performance of the code. - `build:` - Changes to the build system (maven, npm, gulp, etc) - `ci:` - Changes to the CI build system (Travis, GitHub Actions, Circle, etc) - `chore:` - Other changes to project that don't modify source code or test files. - `revert:` - Reverts a previous commit that was made. ### Examples: ``` feat: edit profile photo refactor!: remove deprecated v1 endpoints build: update npm dependencies style: run formatter ``` Need more examples? Want to learn more about this format? [Check out the official docs](https://www.conventionalcommits.org/). **Note:** If your pull request does multiple things such as adding a feature _and_ makes changes to the CI server _and_ fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.