use_native_modules! should take in consideration pod install --project-directory=ios option
#657
Labels
bug
Something isn't working
Comments
2 tasks
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
May 23, 2020
Part of the RN v0.59.10 -> v0.60.0 upgrade [1]. (Or, at least, RN
and most library maintainers assume it is done as such.) This must
happen at or after the upgrade commit because autolinking is a new
feature.
Just like the previous commit, but for iOS.
1. Following the doc [2] as before, unlink everything. Again, with a
script, but this time, only for iOS:
```
for dep in `tools/deps`; do
react-native unlink --platforms=ios "$dep"
done
```
Exclude the same set of Sentry changes as we did in this step for
Android. Also, exclude a change to our Info.plist that would
remove the "Fonts provided by application", a.k.a., `UIAppFonts`.
This is a setup step [3] that we need to keep.
So, we're left with the removal of all items from the "Pods we
need that depend on React Native" list.
Additionally, remove "libz" from our Xcode config. It was put
there by Sentry, as a consequence of running `react-native link`
before we were using CocoaPods. But Sentry expresses the same
dependency in `Sentry.podspec`. So, having it in our Xcode config
is redundant. [4]
2. Make the changes recommended by these commits in
`facebook/react-native`. They follow an A, revert-A, A' pattern,
so you can just look at the third:
261197d85 Implement changes to enable native modules auto linking (#24506)
da7d3dfc7 Partially back out #24506, fixing iOS e2e tests (#24788)
86a97e783 – Bring back autolinking to the iOS template (#25314)
It simply imports and runs a command, `use_native_modules`.
3. Now, go back to `react-native-unimodules` and follow the
">= 0.60" branch of the "Configure iOS" instructions. Turns out
that no changes are needed here; the differences in expressing
our React pod dependencies were handled in the main upgrade
commit, earlier in this series, where we moved to RN v0.60.0.
4. Add our two dependencies that we explicitly do not link on iOS to
the `react-native.config.js`.
5. Add a workaround in `tools/postinstall` for an issue [5] with
running `pod install` from the root directory with
`--project-directory=ios`.
We tried the workaround suggested in that issue, where we have
`use_native_modules!(".")` in the Podfile and still call
`pod install --project-directory=ios` from the root directory.
(This might have led to a cleaner solution, where we pass "." in
the postinstall case, and pass nothing otherwise.) But we got
this error, which isn't addressed in that issue, and doesn't seem
easy to fix without changes to `native_modules.rb`:
```
[!] No podspec found for `RNCAsyncStorage` in `./node_modules/@react-native-community/async-storage`
```
It's plausible that those investigating this issue were only
testing with a template project that didn't have RN-dependent
pods like RNCAsyncStorage, so, never saw this error.
6. Run `pod install` and see that the only change to
`ios/Podfile.lock` is in the checksum. So, job done.
Closes: zulip#4026
[1]: https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.0
[2]: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
[3]: https://github.com/oblador/react-native-vector-icons#option-manually
[4]: There's some uncertainty here; we're not seeing `z` or `libz`
in ios/Pods/Pods.xcodeproj/project.pbxproj after running `pod
install`, with or without autolinking. But it seems to work.
More discussion at
zulip#4026 (comment)
and
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/RN.20autolinking/near/884333.
[5]: react-native-community/cli#657
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 1, 2020
Part of the RN v0.59 -> v0.60 upgrade [1]. (Or, at least, RN and
most library maintainers assume it is done as such.) This must
happen at or after the upgrade commit because autolinking is a new
feature.
Just like the previous commit, but for iOS.
1. Following the doc [2] as before, unlink everything. Again, with a
script, but this time, only for iOS:
```
for dep in `tools/deps`; do
react-native unlink --platforms=ios "$dep"
done
```
Exclude the same set of Sentry changes as we did in this step for
Android. Also, exclude a change to our Info.plist that would
remove the "Fonts provided by application", a.k.a., `UIAppFonts`.
This is a setup step [3] that we need to keep.
So, we're left with the removal of all items from the "Pods we
need that depend on React Native" list.
Additionally, remove "libz" from our Xcode config. It was put
there by Sentry, as a consequence of running `react-native link`
before we were using CocoaPods. But Sentry expresses the same
dependency in `Sentry.podspec`. So, having it in our Xcode config
is redundant. [4]
2. Make the changes recommended by these commits in
`facebook/react-native`. They follow an A, revert-A, A' pattern:
- 261197d85 Implement changes to enable native modules auto
linking (#24506)
- da7d3dfc7 Partially back out #24506, fixing iOS e2e tests
(#24788)
- 86a97e783 – Bring back autolinking to the iOS template (#25314)
It simply imports and runs a command, `use_native_modules`.
3. Now, go back to `react-native-unimodules` and follow the ">=
0.60" branch of the "Configure iOS" instructions. Turns out that
no changes are needed here; the differences in expressing our
React pod dependencies were handled in the main RN v0.60 upgrade
commit.
4. Move the two deps under "RN-dependent Pods that we could include,
but we've decided not to" into the `react-native.config.js`.
5. Add a workaround in `tools/postinstall` for an issue [5] with
running `pod install` from the root directory with
`--project-directory=ios`.
We tried the workaround suggested in that issue, where we have
`use_native_modules!(".")` in the Podfile and still call
`pod install --project-directory=ios` from the root directory.
(This might have led to a cleaner solution, where we pass "." in
the postinstall case, and pass nothing otherwise.) But we got
this error, which isn't addressed in that issue, and doesn't seem
easy to fix without changes to `native_modules.rb`:
```
[!] No podspec found for `RNCAsyncStorage` in `./node_modules/@react-native-community/async-storage`
```
It's plausible that those investigating this issue were only
testing with a template project that didn't have RN-dependent
pods like RNCAsyncStorage, so, never saw this error.
6. Run `pod install` and see that the only change to
`ios/Podfile.lock` is in the checksum. So, job done.
Closes: zulip#4026
[1]: https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.6
[2]: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
[3]: https://github.com/oblador/react-native-vector-icons#option-manually
[4]: There's some uncertainty here; we're not seeing `z` or `libz`
in ios/Pods/Pods.xcodeproj/project.pbxproj after running `pod
install`, with or without autolinking. But it seems to work.
More discussion at
zulip#4026 (comment)
and
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/RN.20autolinking/near/884333.
[5]: react-native-community/cli#657
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 1, 2020
Part of the RN v0.59 -> v0.60 upgrade [1]. (Or, at least, RN and
most library maintainers assume it is done as such.) This must
happen at or after the upgrade commit because autolinking is a new
feature.
Just like the previous commit, but for iOS.
1. Following the doc [2] as before, unlink everything. Again, with a
script, but this time, only for iOS:
```
for dep in `tools/deps`; do
react-native unlink --platforms=ios "$dep"
done
```
Exclude the same set of Sentry changes as we did in this step for
Android. Also, exclude a change to our Info.plist that would
remove the "Fonts provided by application", a.k.a., `UIAppFonts`.
This is a setup step [3] that we need to keep.
So, we're left with the removal of all items from the "Pods we
need that depend on React Native" list.
Additionally, remove "libz" from our Xcode config. It was put
there by Sentry, as a consequence of running `react-native link`
before we were using CocoaPods. But Sentry expresses the same
dependency in `Sentry.podspec`. So, having it in our Xcode config
is redundant. [4]
2. Make the changes recommended by these commits in
`facebook/react-native`. They follow an A, revert-A, A' pattern:
- 261197d85 Implement changes to enable native modules auto
linking (#24506)
- da7d3dfc7 Partially back out #24506, fixing iOS e2e tests
(#24788)
- 86a97e783 – Bring back autolinking to the iOS template (#25314)
It simply imports and runs a command, `use_native_modules`.
3. Now, go back to `react-native-unimodules` and follow the ">=
0.60" branch of the "Configure iOS" instructions. Turns out that
no changes are needed here; the differences in expressing our
React pod dependencies were handled in the main RN v0.60 upgrade
commit.
4. Move the two deps under "RN-dependent Pods that we could include,
but we've decided not to" into the `react-native.config.js`.
5. Add a workaround in `tools/postinstall` for an issue [5] with
running `pod install` from the root directory with
`--project-directory=ios`.
We tried the workaround suggested in that issue, where we have
`use_native_modules!(".")` in the Podfile and still call
`pod install --project-directory=ios` from the root directory.
(This might have led to a cleaner solution, where we pass "." in
the postinstall case, and pass nothing otherwise.) But we got
this error, which isn't addressed in that issue, and doesn't seem
easy to fix without changes to `native_modules.rb`:
```
[!] No podspec found for `RNCAsyncStorage` in `./node_modules/@react-native-community/async-storage`
```
It's plausible that those investigating this issue were only
testing with a template project that didn't have RN-dependent
pods like RNCAsyncStorage, so, never saw this error.
6. Run `pod install` and see that the only change to
`ios/Podfile.lock` is in the checksum. So, job done.
Closes: zulip#4026
[1]: https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.6
[2]: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
[3]: https://github.com/oblador/react-native-vector-icons#option-manually
[4]: There's some uncertainty here; we're not seeing `z` or `libz`
in ios/Pods/Pods.xcodeproj/project.pbxproj after running `pod
install`, with or without autolinking. But it seems to work.
More discussion at
zulip#4026 (comment)
and
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/RN.20autolinking/near/884333.
[5]: react-native-community/cli#657
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 1, 2020
Part of the RN v0.59 -> v0.60 upgrade [1]. (Or, at least, RN and
most library maintainers assume it is done as such.) This must
happen at or after the upgrade commit because autolinking is a new
feature.
Just like the previous commit, but for iOS.
1. Following the doc [2] as before, unlink everything. Again, with a
script, but this time, only for iOS:
```
for dep in `tools/deps`; do
react-native unlink --platforms=ios "$dep"
done
```
Exclude the same set of Sentry changes as we did in this step for
Android. Also, exclude a change to our Info.plist that would
remove the "Fonts provided by application", a.k.a., `UIAppFonts`.
This is a setup step [3] that we need to keep.
So, we're left with the removal of all items from the "Pods we
need that depend on React Native" list.
Additionally, remove "libz" from our Xcode config. It was put
there by Sentry, as a consequence of running `react-native link`
before we were using CocoaPods. But Sentry expresses the same
dependency in `Sentry.podspec`. So, having it in our Xcode config
is redundant. [4]
2. Make the changes recommended by these commits in
`facebook/react-native`. They follow an A, revert-A, A' pattern:
- 261197d85 Implement changes to enable native modules auto
linking (#24506)
- da7d3dfc7 Partially back out #24506, fixing iOS e2e tests
(#24788)
- 86a97e783 – Bring back autolinking to the iOS template (#25314)
It simply imports and runs a command, `use_native_modules`.
3. Now, go back to `react-native-unimodules` and follow the ">=
0.60" branch of the "Configure iOS" instructions. Turns out that
no changes are needed here; the differences in expressing our
React pod dependencies were handled in the main RN v0.60 upgrade
commit.
4. Move the two deps under "RN-dependent Pods that we could include,
but we've decided not to" into the `react-native.config.js`.
5. Add a workaround in `tools/postinstall` for an issue [5] with
running `pod install` from the root directory with
`--project-directory=ios`.
We tried the workaround suggested in that issue, where we have
`use_native_modules!(".")` in the Podfile and still call
`pod install --project-directory=ios` from the root directory.
(This might have led to a cleaner solution, where we pass "." in
the postinstall case, and pass nothing otherwise.) But we got
this error, which isn't addressed in that issue, and doesn't seem
easy to fix without changes to `native_modules.rb`:
```
[!] No podspec found for `RNCAsyncStorage` in `./node_modules/@react-native-community/async-storage`
```
It's plausible that those investigating this issue were only
testing with a template project that didn't have RN-dependent
pods like RNCAsyncStorage, so, never saw this error.
6. Run `pod install` and see that the only change to
`ios/Podfile.lock` is in the checksum. So, job done.
Closes: zulip#4026
[1]: https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.6
[2]: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
[3]: https://github.com/oblador/react-native-vector-icons#option-manually
[4]: There's some uncertainty here; we're not seeing `z` or `libz`
in ios/Pods/Pods.xcodeproj/project.pbxproj after running `pod
install`, with or without autolinking. But it seems to work.
More discussion at
zulip#4026 (comment)
and
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/RN.20autolinking/near/884333.
[5]: react-native-community/cli#657
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 3, 2020
Part of the RN v0.59 -> v0.60 upgrade [1]. (Or, at least, RN and
most library maintainers assume it is done as such.) This must
happen at or after the upgrade commit because autolinking is a new
feature.
Just like the previous commit, but for iOS.
1. Following the doc [2] as before, unlink everything. Again, with a
script, but this time, only for iOS:
```
for dep in `tools/deps`; do
react-native unlink --platforms=ios "$dep"
done
```
Exclude the same set of Sentry changes as we did in this step for
Android. Also, exclude a change to our Info.plist that would
remove the "Fonts provided by application", a.k.a., `UIAppFonts`.
This is a setup step [3] that we need to keep.
So, we're left with the removal of all items from the "Pods we
need that depend on React Native" list.
Additionally, remove "libz" from our Xcode config. It was put
there by Sentry, as a consequence of running `react-native link`
before we were using CocoaPods. But Sentry expresses the same
dependency in `Sentry.podspec`. So, having it in our Xcode config
is redundant. [4]
2. Make the changes recommended by these commits in
`facebook/react-native`. They follow an A, revert-A, A' pattern:
- 261197d85 Implement changes to enable native modules auto
linking (#24506)
- da7d3dfc7 Partially back out #24506, fixing iOS e2e tests
(#24788)
- 86a97e783 – Bring back autolinking to the iOS template (#25314)
It simply imports and runs a command, `use_native_modules`.
3. Now, go back to `react-native-unimodules` and follow the ">=
0.60" branch of the "Configure iOS" instructions. Turns out that
no changes are needed here; the differences in expressing our
React pod dependencies were handled in the main RN v0.60 upgrade
commit.
4. Move the two deps under "RN-dependent Pods that we could include,
but we've decided not to" into the `react-native.config.js`.
5. Add a workaround in `tools/postinstall` for an issue [5] with
running `pod install` from the root directory with
`--project-directory=ios`.
We tried the workaround suggested in that issue, where we have
`use_native_modules!(".")` in the Podfile and still call
`pod install --project-directory=ios` from the root directory.
(This might have led to a cleaner solution, where we pass "." in
the postinstall case, and pass nothing otherwise.) But we got
this error, which isn't addressed in that issue, and doesn't seem
easy to fix without changes to `native_modules.rb`:
```
[!] No podspec found for `RNCAsyncStorage` in
`./node_modules/@react-native-community/async-storage`
```
It's plausible that those investigating this issue were only
testing with a template project that didn't have RN-dependent
pods like RNCAsyncStorage, so, never saw this error.
6. Run `pod install` and see that the only change to
`ios/Podfile.lock` is in the checksum. So, job done.
[1]: https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.6
[2]: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
[3]: https://github.com/oblador/react-native-vector-icons#option-manually
[4]: There's some uncertainty here; we're not seeing `z` or `libz`
in ios/Pods/Pods.xcodeproj/project.pbxproj after running `pod
install`, with or without autolinking. But it seems to work.
More discussion at
zulip#4026 (comment)
and
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/RN.20autolinking/near/884333.
[5]: react-native-community/cli#657
Fixes: zulip#4026
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 3, 2020
Part of the RN v0.59 -> v0.60 upgrade [1]. (Or, at least, RN and
most library maintainers assume it is done as such.) This must
happen at or after the upgrade commit because autolinking is a new
feature.
Just like the previous commit, but for iOS.
1. Following the doc [2] as before, unlink everything. Again, with a
script, but this time, only for iOS:
```
for dep in `tools/deps`; do
react-native unlink --platforms=ios "$dep"
done
```
Exclude the same set of Sentry changes as we did in this step for
Android. Also, exclude a change to our Info.plist that would
remove the "Fonts provided by application", a.k.a., `UIAppFonts`.
This is a setup step [3] that we need to keep.
So, we're left with the removal of all items from the "Pods we
need that depend on React Native" list.
Additionally, remove "libz" from our Xcode config. It was put
there by Sentry, as a consequence of running `react-native link`
before we were using CocoaPods. But Sentry expresses the same
dependency in `Sentry.podspec`. So, having it in our Xcode config
is redundant. [4]
2. Make the changes recommended by these commits in
`facebook/react-native`. They follow an A, revert-A, A' pattern:
- 261197d85 Implement changes to enable native modules auto
linking (#24506)
- da7d3dfc7 Partially back out #24506, fixing iOS e2e tests
(#24788)
- 86a97e783 – Bring back autolinking to the iOS template (#25314)
It simply imports and runs a command, `use_native_modules`.
3. Now, go back to `react-native-unimodules` and follow the ">=
0.60" branch of the "Configure iOS" instructions. Turns out that
no changes are needed here; the differences in expressing our
React pod dependencies were handled in the main RN v0.60 upgrade
commit.
4. Move the two deps under "RN-dependent Pods that we could include,
but we've decided not to" into the `react-native.config.js`.
5. Add a workaround in `tools/postinstall` for an issue [5] with
running `pod install` from the root directory with
`--project-directory=ios`.
We tried the workaround suggested in that issue, where we have
`use_native_modules!(".")` in the Podfile and still call
`pod install --project-directory=ios` from the root directory.
(This might have led to a cleaner solution, where we pass "." in
the postinstall case, and pass nothing otherwise.) But we got
this error, which isn't addressed in that issue, and doesn't seem
easy to fix without changes to `native_modules.rb`:
```
[!] No podspec found for `RNCAsyncStorage` in
`./node_modules/@react-native-community/async-storage`
```
It's plausible that those investigating this issue were only
testing with a template project that didn't have RN-dependent
pods like RNCAsyncStorage, so, never saw this error.
6. Run `pod install` and see that the only change to
`ios/Podfile.lock` is in the checksum. So, job done.
[1]: https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.6
[2]: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
[3]: https://github.com/oblador/react-native-vector-icons#option-manually
[4]: There's some uncertainty here; we're not seeing `z` or `libz`
in ios/Pods/Pods.xcodeproj/project.pbxproj after running `pod
install`, with or without autolinking. But it seems to work.
More discussion at
zulip#4026 (comment)
and
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/RN.20autolinking/near/884333.
[5]: react-native-community/cli#657
Fixes: zulip#4026
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 4, 2020
Part of the RN v0.59 -> v0.60 upgrade [1]. (Or, at least, RN and
most library maintainers assume it is done as such.) This must
happen at or after the upgrade commit because autolinking is a new
feature.
Just like the previous commit, but for iOS.
1. Following the doc [2] as before, unlink everything. Again, with a
script, but this time, only for iOS:
```
for dep in `tools/deps`; do
react-native unlink --platforms=ios "$dep"
done
```
Exclude the same set of Sentry changes as we did in this step for
Android. Also, exclude a change to our Info.plist that would
remove the "Fonts provided by application", a.k.a., `UIAppFonts`.
This is a setup step [3] that we need to keep.
So, we're left with the removal of all items from the "Pods we
need that depend on React Native" list.
Additionally, remove "libz" from our Xcode config. It was put
there by Sentry, as a consequence of running `react-native link`
before we were using CocoaPods. But Sentry expresses the same
dependency in `Sentry.podspec`. So, having it in our Xcode config
is redundant. [4]
2. Make the change recommended by `facebook/react-native@86a97e783`:
import and call a method, `use_native_modules!`.
3. Now, go back to `react-native-unimodules` and follow the
">= 0.60" branch of the "Configure iOS" instructions. Turns out
that no changes are needed here; the differences in expressing
our React pod dependencies were handled in the main RN v0.60
upgrade commit.
4. Move the two deps under "RN-dependent Pods that we could include,
but we've decided not to" into the `react-native.config.js`.
5. Add a workaround in `tools/postinstall` for an issue [5] with
running `pod install` from the root directory with
`--project-directory=ios`.
We tried the workaround suggested in that issue, where we have
`use_native_modules!(".")` in the Podfile and still call
`pod install --project-directory=ios` from the root directory.
(This might have led to a cleaner solution, where we pass "." in
the postinstall case, and pass nothing otherwise.) But we got
this error, which isn't addressed in that issue, and doesn't seem
easy to fix without changes to `native_modules.rb`:
```
[!] No podspec found for `RNCAsyncStorage` in
`./node_modules/@react-native-community/async-storage`
```
It's plausible that those investigating this issue were only
testing with a template project that didn't have RN-dependent
pods like RNCAsyncStorage, so, never saw this error.
6. Run `pod install` and see that the only change to
`ios/Podfile.lock` is in the checksum. So, job done.
[1]: https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.6
[2]: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
[3]: https://github.com/oblador/react-native-vector-icons#option-manually
[4]: There's some uncertainty here; we're not seeing `z` or `libz`
in ios/Pods/Pods.xcodeproj/project.pbxproj after running `pod
install`, with or without autolinking. But it seems to work.
More discussion at
zulip#4026 (comment)
and
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/RN.20autolinking/near/884333.
[5]: react-native-community/cli#657
Fixes: zulip#4026
chrisbobbe
added a commit
to zulip/zulip-mobile
that referenced
this issue
Jun 4, 2020
Part of the RN v0.59 -> v0.60 upgrade [1]. (Or, at least, RN and
most library maintainers assume it is done as such.) This must
happen at or after the upgrade commit because autolinking is a new
feature.
Just like the previous commit, but for iOS.
1. Following the doc [2] as before, unlink everything. Again, with a
script, but this time, only for iOS:
```
for dep in `tools/deps`; do
react-native unlink --platforms=ios "$dep"
done
```
Exclude the same set of Sentry changes as we did in this step for
Android. Also, exclude a change to our Info.plist that would
remove the "Fonts provided by application", a.k.a., `UIAppFonts`.
This is a setup step [3] that we need to keep.
So, we're left with the removal of all items from the "Pods we
need that depend on React Native" list.
Additionally, remove "libz" from our Xcode config. It was put
there by Sentry, as a consequence of running `react-native link`
before we were using CocoaPods. But Sentry expresses the same
dependency in `Sentry.podspec`. So, having it in our Xcode config
is redundant. [4]
2. Make the change recommended by `facebook/react-native@86a97e783`:
import and call a method, `use_native_modules!`.
3. Now, go back to `react-native-unimodules` and follow the
">= 0.60" branch of the "Configure iOS" instructions. Turns out
that no changes are needed here; the differences in expressing
our React pod dependencies were handled in the main RN v0.60
upgrade commit.
4. Move the two deps under "RN-dependent Pods that we could include,
but we've decided not to" into the `react-native.config.js`.
5. Add a workaround in `tools/postinstall` for an issue [5] with
running `pod install` from the root directory with
`--project-directory=ios`.
We tried the workaround suggested in that issue, where we have
`use_native_modules!(".")` in the Podfile and still call
`pod install --project-directory=ios` from the root directory.
(This might have led to a cleaner solution, where we pass "." in
the postinstall case, and pass nothing otherwise.) But we got
this error, which isn't addressed in that issue, and doesn't seem
easy to fix without changes to `native_modules.rb`:
```
[!] No podspec found for `RNCAsyncStorage` in
`./node_modules/@react-native-community/async-storage`
```
It's plausible that those investigating this issue were only
testing with a template project that didn't have RN-dependent
pods like RNCAsyncStorage, so, never saw this error.
6. Run `pod install` and see that the only change to
`ios/Podfile.lock` is in the checksum. So, job done.
[1]: https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.6
[2]: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
[3]: https://github.com/oblador/react-native-vector-icons#option-manually
[4]: There's some uncertainty here; we're not seeing `z` or `libz`
in ios/Pods/Pods.xcodeproj/project.pbxproj after running `pod
install`, with or without autolinking. But it seems to work.
More discussion at
#4026 (comment)
and
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/RN.20autolinking/near/884333.
[5]: react-native-community/cli#657
Fixes: #4026
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 5, 2020
Part of the RN v0.59 -> v0.60 upgrade [1]. (Or, at least, RN and
most library maintainers assume it is done as such.) This must
happen at or after the upgrade commit because autolinking is a new
feature.
Just like the previous commit, but for iOS.
1. Following the doc [2] as before, unlink everything. Again, with a
script, but this time, only for iOS:
```
for dep in `tools/deps`; do
react-native unlink --platforms=ios "$dep"
done
```
Exclude the same set of Sentry changes as we did in this step for
Android. Also, exclude a change to our Info.plist that would
remove the "Fonts provided by application", a.k.a., `UIAppFonts`.
This is a setup step [3] that we need to keep.
So, we're left with the removal of all items from the "Pods we
need that depend on React Native" list.
Additionally, remove "libz" from our Xcode config. It was put
there by Sentry, as a consequence of running `react-native link`
before we were using CocoaPods. But Sentry expresses the same
dependency in `Sentry.podspec`. So, having it in our Xcode config
is redundant. [4]
2. Make the change recommended by `facebook/react-native@86a97e783`:
import and call a method, `use_native_modules!`.
3. Now, go back to `react-native-unimodules` and follow the
">= 0.60" branch of the "Configure iOS" instructions. Turns out
that no changes are needed here; the differences in expressing
our React pod dependencies were handled in the main RN v0.60
upgrade commit.
4. Move the two deps under "RN-dependent Pods that we could include,
but we've decided not to" into the `react-native.config.js`.
5. Add a workaround in `tools/postinstall` for an issue [5] with
running `pod install` from the root directory with
`--project-directory=ios`.
We tried the workaround suggested in that issue, where we have
`use_native_modules!(".")` in the Podfile and still call
`pod install --project-directory=ios` from the root directory.
(This might have led to a cleaner solution, where we pass "." in
the postinstall case, and pass nothing otherwise.) But we got
this error, which isn't addressed in that issue, and doesn't seem
easy to fix without changes to `native_modules.rb`:
```
[!] No podspec found for `RNCAsyncStorage` in
`./node_modules/@react-native-community/async-storage`
```
It's plausible that those investigating this issue were only
testing with a template project that didn't have RN-dependent
pods like RNCAsyncStorage, so, never saw this error.
6. Run `pod install` and see that the only change to
`ios/Podfile.lock` is in the checksum. So, job done.
[1]: https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.6
[2]: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
[3]: https://github.com/oblador/react-native-vector-icons#option-manually
[4]: There's some uncertainty here; we're not seeing `z` or `libz`
in ios/Pods/Pods.xcodeproj/project.pbxproj after running `pod
install`, with or without autolinking. But it seems to work.
More discussion at
zulip#4026 (comment)
and
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/RN.20autolinking/near/884333.
[5]: react-native-community/cli#657
Fixes: zulip#4026
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 5, 2020
Part of the RN v0.59 -> v0.60 upgrade [1]. (Or, at least, RN and
most library maintainers assume it is done as such.) This must
happen at or after the upgrade commit because autolinking is a new
feature.
Just like the previous commit, but for iOS.
1. Following the doc [2] as before, unlink everything. Again, with a
script, but this time, only for iOS:
```
for dep in `tools/deps`; do
react-native unlink --platforms=ios "$dep"
done
```
Exclude the same set of Sentry changes as we did in this step for
Android. Also, exclude a change to our Info.plist that would
remove the "Fonts provided by application", a.k.a., `UIAppFonts`.
This is a setup step [3] that we need to keep.
So, we're left with the removal of all items from the "Pods we
need that depend on React Native" list.
Additionally, remove "libz" from our Xcode config. It was put
there by Sentry, as a consequence of running `react-native link`
before we were using CocoaPods. But Sentry expresses the same
dependency in `Sentry.podspec`. So, having it in our Xcode config
is redundant. [4]
2. Make the change recommended by facebook/react-native@86a97e783:
import and call a method, `use_native_modules!`.
3. Now, go back to `react-native-unimodules` and follow the
">= 0.60" branch of the "Configure iOS" instructions. Turns out
that no changes are needed here; the differences in expressing
our React pod dependencies were handled in the main RN v0.60
upgrade commit.
4. Move the two deps under "RN-dependent Pods that we could include,
but we've decided not to" into the `react-native.config.js`.
5. Add a workaround in `tools/postinstall` for an issue [5] with
running `pod install` from the root directory with
`--project-directory=ios`.
We tried the workaround suggested in that issue, where we have
`use_native_modules!(".")` in the Podfile and still call
`pod install --project-directory=ios` from the root directory.
(This might have led to a cleaner solution, where we pass "." in
the postinstall case, and pass nothing otherwise.) But we got
this error, which isn't addressed in that issue, and doesn't seem
easy to fix without changes to `native_modules.rb`:
```
[!] No podspec found for `RNCAsyncStorage` in
`./node_modules/@react-native-community/async-storage`
```
It's plausible that those investigating this issue were only
testing with a template project that didn't have RN-dependent
pods like RNCAsyncStorage, so, never saw this error.
6. Run `pod install` and see that the only change to
`ios/Podfile.lock` is in the checksum. So, job done.
[1]: https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.6
[2]: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
[3]: https://github.com/oblador/react-native-vector-icons#option-manually
[4]: There's some uncertainty here; we're not seeing `z` or `libz`
in ios/Pods/Pods.xcodeproj/project.pbxproj after running `pod
install`, with or without autolinking. But it seems to work.
More discussion at
zulip#4026 (comment)
and
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/RN.20autolinking/near/884333.
[5]: react-native-community/cli#657
Fixes: zulip#4026
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 8, 2020
Part of the RN v0.59 -> v0.60 upgrade [1]. (Or, at least, RN and
most library maintainers assume it is done as such.) This must
happen at or after the upgrade commit because autolinking is a new
feature.
Just like the previous commit, but for iOS.
1. Following the doc [2] as before, unlink everything. Again, with a
script, but this time, only for iOS:
```
for dep in `tools/deps`; do
react-native unlink --platforms=ios "$dep"
done
```
Exclude the same set of Sentry changes as we did in this step for
Android. Also, exclude a change to our Info.plist that would
remove the "Fonts provided by application", a.k.a., `UIAppFonts`.
This is a setup step [3] that we need to keep.
So, we're left with the removal of all items from the "Pods we
need that depend on React Native" list.
Additionally, remove "libz" from our Xcode config. It was put
there by Sentry, as a consequence of running `react-native link`
before we were using CocoaPods. But Sentry expresses the same
dependency in `Sentry.podspec`. So, having it in our Xcode config
is redundant. [4]
2. Make the change recommended by facebook/react-native@86a97e783:
import and call a method, `use_native_modules!`.
3. Now, go back to `react-native-unimodules` and follow the
">= 0.60" branch of the "Configure iOS" instructions. Turns out
that no changes are needed here; the differences in expressing
our React pod dependencies were handled in the main RN v0.60
upgrade commit.
4. Move the two deps under "RN-dependent Pods that we could include,
but we've decided not to" into the `react-native.config.js`.
5. Add a workaround in `tools/postinstall` for an issue [5] with
running `pod install` from the root directory with
`--project-directory=ios`.
We tried the workaround suggested in that issue, where we have
`use_native_modules!(".")` in the Podfile and still call
`pod install --project-directory=ios` from the root directory.
(This might have led to a cleaner solution, where we pass "." in
the postinstall case, and pass nothing otherwise.) But we got
this error, which isn't addressed in that issue, and doesn't seem
easy to fix without changes to `native_modules.rb`:
```
[!] No podspec found for `RNCAsyncStorage` in
`./node_modules/@react-native-community/async-storage`
```
It's plausible that those investigating this issue were only
testing with a template project that didn't have RN-dependent
pods like RNCAsyncStorage, so, never saw this error.
6. Run `pod install` and see that the only change to
`ios/Podfile.lock` is in the checksum. So, job done.
[1]: https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.6
[2]: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
[3]: https://github.com/oblador/react-native-vector-icons#option-manually
[4]: There's some uncertainty here; we're not seeing `z` or `libz`
in ios/Pods/Pods.xcodeproj/project.pbxproj after running `pod
install`, with or without autolinking. But it seems to work.
More discussion at
zulip#4026 (comment)
and
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/RN.20autolinking/near/884333.
[5]: react-native-community/cli#657
Fixes: zulip#4026
gnprice
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 8, 2020
Part of the RN v0.59 -> v0.60 upgrade [1]. (Or, at least, RN and
most library maintainers assume it is done as such.) This must
happen at or after the upgrade commit because autolinking is a new
feature.
Just like the previous commit, but for iOS.
1. Following the doc [2] as before, unlink everything. Again, with a
script, but this time, only for iOS:
```
for dep in `tools/deps`; do
react-native unlink --platforms=ios "$dep"
done
```
Exclude the same set of Sentry changes as we did in this step for
Android. Also, exclude a change to our Info.plist that would
remove the "Fonts provided by application", a.k.a., `UIAppFonts`.
This is a setup step [3] that we need to keep.
So, we're left with the removal of all items from the "Pods we
need that depend on React Native" list.
Additionally, remove "libz" from our Xcode config. It was put
there by Sentry, as a consequence of running `react-native link`
before we were using CocoaPods. But Sentry expresses the same
dependency in `Sentry.podspec`. So, having it in our Xcode config
is redundant. [4]
2. Make the change recommended by facebook/react-native@86a97e783:
import and call a method, `use_native_modules!`.
3. Now, go back to `react-native-unimodules` and follow the
">= 0.60" branch of the "Configure iOS" instructions. Turns out
that no changes are needed here; the differences in expressing
our React pod dependencies were handled in the main RN v0.60
upgrade commit.
4. Move the two deps under "RN-dependent Pods that we could include,
but we've decided not to" into the `react-native.config.js`.
5. Add a workaround in `tools/postinstall` for an issue [5] with
running `pod install` from the root directory with
`--project-directory=ios`.
We tried the workaround suggested in that issue, where we have
`use_native_modules!(".")` in the Podfile and still call
`pod install --project-directory=ios` from the root directory.
(This might have led to a cleaner solution, where we pass "." in
the postinstall case, and pass nothing otherwise.) But we got
this error, which isn't addressed in that issue, and doesn't seem
easy to fix without changes to `native_modules.rb`:
```
[!] No podspec found for `RNCAsyncStorage` in
`./node_modules/@react-native-community/async-storage`
```
It's plausible that those investigating this issue were only
testing with a template project that didn't have RN-dependent
pods like RNCAsyncStorage, so, never saw this error.
6. Run `pod install` and see that the only change to
`ios/Podfile.lock` is in the checksum. So, job done.
[1]: https://react-native-community.github.io/upgrade-helper/?from=0.59.10&to=0.60.6
[2]: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
[3]: https://github.com/oblador/react-native-vector-icons#option-manually
[4]: There's some uncertainty here; we're not seeing `z` or `libz`
in ios/Pods/Pods.xcodeproj/project.pbxproj after running `pod
install`, with or without autolinking. But it seems to work.
More discussion at
zulip#4026 (comment)
and
https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/RN.20autolinking/near/884333.
[5]: react-native-community/cli#657
Fixes: zulip#4026
|
I'm sorry has this issue been resolved? How do I pick up the fix? |
|
@MoOx I tried to use the workaround you described
|
|
if it helps... when I : It worked for me |
in your podfile, change the path from './node_modules/react-native-linear-gradient' to '../node_modules/react-native-linear-gradient |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
Description
If you don't run
pod installfrom./iosfolder (eg: viapod install --project-directory=iosinstead ofcd ios && pod install, you can get this errorIn this precise scenario, (
pod installwith--project-directory=ios), usinguse_native_modules!(".")instead ofuse_native_modules!does the trick (as default root value is"..").That said, it's not a safe option as now, running
pod installfromiosfolder won't work anymore.Maybe this tool should take
--project-directoryoption in consideration.Reproducible Demo
You can reproduce this with any project that
@react-native-community/cli-platform-ios" "^3.0.0-alpha.2or something around thatuse_native_modules!in theios/PodfileRun from the root of the project (and not
./ios)pod install --project-directory=iosThe text was updated successfully, but these errors were encountered: