-
-
Notifications
You must be signed in to change notification settings - Fork 643
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CocoaPods near-term followup #4028
Commits on Apr 10, 2020
-
cocoapods: Automate
pod install
withpostinstall
script.Chris Bobbe committedApr 10, 2020 Configuration menu - View commit details
-
Copy full SHA for e66604d - Browse repository at this point
Copy the full SHA e66604dView commit details -
howto/ios-tips: Make sure to run .xcworkspace, not .xcodeproj.
Chris Bobbe committedApr 10, 2020 Configuration menu - View commit details
-
Copy full SHA for 487ee09 - Browse repository at this point
Copy the full SHA 487ee09View commit details -
howto/build-run: Also suggest starting out with Xcode/Android Studio.
Chris Bobbe committedApr 10, 2020 Configuration menu - View commit details
-
Copy full SHA for c96e3b8 - Browse repository at this point
Copy the full SHA c96e3b8View commit details -
docs/architecture: Remove long-outdated bit.
There's a lot more that could be improved in this doc; at zulip#3307 (comment), we noted that we don't want to keep an up-to-date doc of everything in the /src directory; everything should be done inline.
Chris Bobbe committedApr 10, 2020 Configuration menu - View commit details
-
Copy full SHA for 24f50dd - Browse repository at this point
Copy the full SHA 24f50ddView commit details -
ios docs: Suggest clearing the build folders.
Chris Bobbe committedApr 10, 2020 Configuration menu - View commit details
-
Copy full SHA for 75f4946 - Browse repository at this point
Copy the full SHA 75f4946View commit details -
deps: Fix peer dependency warning with expo-application.
On expo-application v2.1.0 (see 18c37ce), we were seeing this warning on initial runs of `yarn`: warning " > expo-application@2.1.0" has unmet peer dependency "@unimodules/core@~1.0.0". (Same as in 5b6014e: "No such warning if `yarn` stops after step 'Resolving packages' and prints 'Already up-to-date'; but if it has any actual work to do, it always shows this warning in step 'Linking dependencies'.) Version 2.1.0 of expo-application declares that it depends on a version of @unimodules/core (1.0.0) that was already several months out-of-date at the time expo-application was first created, and it seems unlikely that this was well-considered. I filed expo/expo#7728 for this, and it was promptly addressed by releasing version 2.1.1 of expo-application that had "*" for its version constraint on the @unimodules/core peer dependency. So, switch to that new version. Even when we do that, though, we get the following: warning " > expo-application@2.1.1" has unmet peer dependency "@unimodules/core@*". This goes away when we declare a version of @unimodules/core in our own dependencies, though. Greg did some digging and concluded that this is likely what we're supposed to do, actually, because it's declared as a "peer dependency": """ Here's the reference doc for it: https://docs.npmjs.com/files/package.json#peerdependencies but it's not very clear about what it actually *means* -- mostly it just describes a use-case. The closest I've found to clear docs on it may be this Yarn blog post: https://classic.yarnpkg.com/blog/2018/04/18/dependencies-done-right/ > The `peerDependencies` object guarantees that, for each entry, any > package that requires you will be requested to provide a copy of > the dependency listed here, ideally matching the version you > requested. It also guarantees that you’ll be able to access this > dependency through `require()`, and finally **it also guarantees > that the return of `require()` will be exactly the same version & > instance than the one your parent would obtain if they were to > `require()` it themselves**. [emphasis in original] And if you work through the consequences of that... it means in particular that the "parent" has to have that dependency and be able to `require()` it themselves. Which, if you're declaring your dependencies cleanly, means the parent should have it as a dependency in their own `package.json`. """ So, declare @unimodules/core in our own "dependencies", with the version specified by react-native-unimodules in its active version. This matching should be done each time we change versions of react-native-unimodules.
Chris Bobbe committedApr 10, 2020 Configuration menu - View commit details
-
Copy full SHA for bc27f2d - Browse repository at this point
Copy the full SHA bc27f2dView commit details