Prevent errors if podspecPath is undefined

[deggertsen]

I ran into a case where the podspecPath was undefined while running yarn prepare. Rather than throwing an error because you can't split something that is undefined, we should simply set it as an empty string. This is assuming we shouldn't instead catch the error and present a meaningful resolution.

Why

To prevent errors if the podspecPath is undefined.

How

It was preventing yarn prepare from running successfully and otherwise doesn't seem to have adverse effects.

Test Plan

It would be good to test with other plugins running yarn prepare, but it's a small change that shouldn't have adverse effects unless there is a reason we should be catching if the podspecPath is not defined. If so, we should instead throw a meaningful error.

Checklist

• Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md).
• Conforms with the Documentation Writing Style Guide
• This diff will work correctly for expo prebuild & EAS Build (eg: updated a module plugin).

[expo-bot]

Hi there! 👋 I'm a bot whose goal is to ensure your contributions meet our guidelines.

I've found some issues in your pull request that should be addressed (click on them for more details) 👇

⚠️ Suggestion: Missing changelog entries

Your changes should be noted in the changelog. Read Updating Changelogs guide and consider adding an appropriate entry to the following changelogs:

• packages/expo-module-scripts/CHANGELOG.md

---

Generated by ExpoBot 🤖 against 92fb8bb

[ide]

Instead of treating the path as an empty string, we should either throw a clear error or write code specifically for this use case that produces output that makes sense. Specifically, it looks like this code intends to replace "podName" in the readme template, and we would need to handle the case where there is no pod name.

[deggertsen]

Got the error while running yarn prepare after creating an expo plugin. I'm not sure why there would be a missing podName as my plugin wasn't messing with pods at all. I just wanted my plugin to build.

It's fine if we want to close this PR, but I thought I would throw it out there just in case this isn't supposed to prevent plugins from building.

[ide]

@EvanBacon It sounds like expo-module-scripts is trying to generate a README for some reason. Is this unexpected behavior (I think it is?)?

[JoshKeenan]

@ide I am currently unable to complete a build on eas servers as the patch package sadly has no effect on the packages used in the prebuild phase on eas severs. I believe and the fact that this can't generate a readme as I have no associated podspec with my config plugin has completely stopped any build progress. I have been able to build and prepare the plugin on my machine with no issues but can't create a development build as this segment can't find a podspec. Any chances of this being patched anytime soon?

[ide]

This is an old PR and I don't recall much of the context behind it other than that is appeared to fix a symptom rather than a cause. My understanding is the root cause needs deeper investigation for a PR to be accepted.

[JoshKeenan]

Is there a way to disable this file from running when generating config plugins at all? If not have you got any suggestions for a mitigation/evasion strategy so that config plugins not related to a particular podspecPath could be built in the meantime?

[EvanBacon]

Please add a changelog entry for this bugfix

[ide]

@byCedric will take a closer look at this PR this week. I suspect there are several changes needed, namely:

1. If podspecs is empty, throw a clear error:

throw new Error(
  `The Expo module named "${packageName}" contains an "ios" directory but does not define a Podspec, which is required for modules with iOS implementations.`
)

This way, we fail instead of masking a symptom.

2. Call generateREADME only when it’s applicable. I’m not sure what those conditions are, but considering that this script starts with const DEFAULT_HOMEPAGE = 'https://docs.expo.dev/versions/latest/';, I think this shouldn’t run for modules that aren’t maintained by the Expo team. This is likely related to the root cause of the error at hand.