Skip to content
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

Merged
merged 6 commits into from
Apr 10, 2020
Merged

Commits on Apr 10, 2020

  1. Configuration menu
    Copy the full SHA
    e66604d View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    487ee09 View commit details
    Browse the repository at this point in the history
  3. Configuration menu
    Copy the full SHA
    c96e3b8 View commit details
    Browse the repository at this point in the history
  4. 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 committed Apr 10, 2020
    Configuration menu
    Copy the full SHA
    24f50dd View commit details
    Browse the repository at this point in the history
  5. ios docs: Suggest clearing the build folders.

    Chris Bobbe committed Apr 10, 2020
    Configuration menu
    Copy the full SHA
    75f4946 View commit details
    Browse the repository at this point in the history
  6. 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 committed Apr 10, 2020
    Configuration menu
    Copy the full SHA
    bc27f2d View commit details
    Browse the repository at this point in the history