rgomezp/expo-pod-pinner

The Pod Pinner plugin allows you to modify your Podfile in a managed workflow.

Welcome to Expo Pod Pinner 👋

A Config Plugin for Expo to specify and pin pod versions directly in your project's Podfile without leaving the managed workflow.

Overview

This plugin is an Expo Config Plugin designed to enhance your Expo managed workflow by allowing direct modification of the Podfile to pin specific CocoaPods dependencies to desired versions. With Expo Pod Pinner, you can ensure consistent dependency versions across installations and updates, enhancing project stability.

Supported Environments:

• The Expo run commands (expo run:[android|ios])
• Custom clients
• EAS Build

Install

npx expo install expo-pod-pinner

Configuration in app.json / app.config.js

Plugin

Add the plugin to your plugin array in your project's configuration file. Configure any desired plugin props as follows:

app.json

{
  "plugins": [
    [
      "expo-pod-pinner",
      {
        "targetName": "YourTargetName",
        "pods": [
          { "PodName": "0.0.0" }
        ]
      }
    ]
  ]
}

or

app.config.js

export default {
  ...
  plugins: [
      [
        "expo-pod-pinner",
        {
          "targetName": "YourTargetName",
          "pods": [
            { "PodName": "Version" }
          ]
      }
      ]
  ]
};

Plugin Props

Configure the plugin using the following props in the plugin config object:

Prop	Type	Description
targetName	string	The name of the target in your Podfile where the pods should be added.
pods	array	An array of objects specifying the pod names and their versions.

Prebuild (optional)

Prebuilding in Expo will result in the generation of the native runtime code for the project (and ios and android directories being built). By prebuilding, we automatically link and configure the native modules that have implemented CocoaPods, autolinking, and other config plugins. You can think of prebuild like a native code bundler.

When you run expo prebuild we enter into a custom managed workflow which provides most of the benefits of bare workflows and managed workflows at the same time.

Why should I prebuild?

It may make sense to prebuild locally to inspect config plugin changes and help in debugging issues.

Run

npx expo prebuild

# nukes changes and rebuilds
npx expo prebuild --clean

EAS Note: if you choose to stay in a fully managed workflow by not prebuilding, EAS will still run npx expo prebuild at build time. You can also prebuild locally but remain in a fully managed workflow by adding the android and ios directories to your .gitignore.

---

🤝 Contributing

Contributions, issues and feature requests are welcome!
Feel free to check issues page.

Show your support

Give a ⭐️ if this project helped you!

expo-pod-pinner's Issues

[Bug]: Pinning pod removes extra targets in podfile

What happened?

When pinning a pod version, if a later plugin changes the podfile, these changes are lost

Steps to reproduce?

1. Install Onesignal react native expo plugin
2. Install ExpoPodPinner
3. List ExpoPodPinner followed by Onesignal native expo plugin in plugins
4. Run expo prebuild for ios
5. Observe missing 'OneSignalNotificationServiceExtension' target.

Swap the order and observe OneSignalNotificationServiceExtension target is present.

What did you expect to happen?

Plugin order to not change behaviour

Expo Pod Pinner Plugin version

1.0.0

Platform

iOS

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct