Skip to content

🐛 Bug Report: Issue with Expo #43

Closed

Description

@mi5ha

👟 Reproduction steps

When installing react-native-appwrite in current Expo project (v52.0.28), there is a conflict with several package versions (metro, metro-resolver, metro-config)

To see an issue run:

npx expo-doctor

The reason this happens is because the way package.json is defined.

It sets both "dependencies" and "peerDependencies". Because "dependencies" are more restrictive this versioning issue happens.

Probably "dependencies" should be removed and just "peerDependencies" kept? That would solve versions issue I think.

👍 Expected behavior

Versions issues should not be reported.

👎 Actual Behavior

Expo doctor shows these issues:

Detailed check results:

Expected package metro@^0.81.0
Found invalid:
  metro@0.80.12
  (for more info, run: npm why metro)
Expected package metro-resolver@^0.81.0
Found invalid:
  metro-resolver@0.80.12
  (for more info, run: npm why metro-resolver)
Expected package metro-config@^0.81.0
Found invalid:
  metro-config@0.80.12
  (for more info, run: npm why metro-config)

🎲 Appwrite version

Version 0.7.x

💻 Operating system

MacOS

🧱 Your Environment

No response

👀 Have you spent some time to check if this issue has been raised before?

  • I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

Activity

  1. mi5ha commented on Jan 29, 2025

    @mi5ha
    Author

    As a temp solution putting this into package.json removes the doctor issues:

      "overrides": {
        "react-native-appwrite": {
          "react-native": "0.76.6",
          "expo-file-system": "^18.0.7"
        }
      }
    
  2. rparida1052 commented on Feb 13, 2025

    @rparida1052

    This solution did not work

  3. mi5ha commented on Feb 13, 2025

    @mi5ha
    Author

    This solution did not work

    Did you pair it with your versions of react-native and expo-file-system?

    Btw its maybe better to add ^ for react-native also:

    "react-native": "^0.76.6",
    
  4. rparida1052 commented on Feb 13, 2025

    @rparida1052

    yes,sure

  5. viju-sharma commented on Feb 27, 2025

    @viju-sharma

    As a temp solution putting this into package.json removes the doctor issues:

      "overrides": {
        "react-native-appwrite": {
          "react-native": "0.76.6",
          "expo-file-system": "^18.0.7"
        }
      }
    

    Hey, It did not fix the issue, can you please help ?

  6. 1stepdev commented on Mar 14, 2025

    @1stepdev

    Same problem here reported by expo doctor:

    ✖ Check that native modules use compatible support package versions for installed Expo SDK
    Expected package metro@^0.81.0
      Found invalid:
        metro@0.80.12
        (for more info, run: npm why metro)
    Expected package metro-resolver@^0.81.0
      Found invalid:
        metro-resolver@0.80.12
        (for more info, run: npm why metro-resolver)
      Expected package metro-config@^0.81.0
      Found invalid:
        metro-config@0.80.12
        (for more info, run: npm why metro-config)
      Advice: Upgrade dependencies that are using the invalid package versions.
    
    

    npm ls metro show that:

    ├─┬ react-native-appwrite@0.7.0
    │ └─┬ react-native@0.73.11
    │   └─┬ @react-native/community-cli-plugin@0.73.18
    │     ├─┬ metro-config@0.80.12
    │     │ └── metro@0.80.12 deduped
    │     └─┬ metro@0.80.12
    │       └─┬ metro-transform-worker@0.80.12
    │         └── metro@0.80.12 deduped
    └─┬ react-native@0.76.7
      └─┬ @react-native/community-cli-plugin@0.76.7
        ├─┬ metro-config@0.81.1
        │ └── metro@0.81.1 deduped
        └─┬ metro@0.81.1
          └─┬ metro-transform-worker@0.81.1
            └── metro@0.81.1 deduped
    
    

    What is the correct way to handle that ?
    Can the react native appwrite sdk be updated to last version of react native ?

  7. ChiragAgg5k commented on Mar 17, 2025

    @ChiragAgg5k
    Member

    @mi5ha thanks for raising this issue. The team has noted the issue down and will release a fix soon 🙏

  8. self-assigned this
    on Mar 17, 2025
  9. added theissue type on Mar 17, 2025
  10. added this to 1.6 Release and removed this from 1.6 Releaseon Mar 17, 2025
  11. ChiragAgg5k commented on Mar 17, 2025

    @ChiragAgg5k
    Member

    Closing as this should be fixed with latest release 0.7.2

  12. mi5ha commented on Mar 17, 2025

    @mi5ha
    Author

    Closing as this should be fixed with latest release 0.7.2

    @ChiragAgg5k Thank you it is fixed!

    But I am afraid the issue will resurface again when versions of react-native and expo-file-system are updated.

    Btw what is the reason for having both dependencies and peerDependencies? Why just not have only peerDependencies?

  13. ChiragAgg5k commented on Mar 18, 2025

    @ChiragAgg5k
    Member

    @mi5ha there is a great article that i think you should read to learn the distinction between them - https://medium.com/@DevChris01/npm-dependencies-vs-devdependencies-vs-peerdependencies-82760bd630d

    TLDR - peerDependencies are required by users who use the react-native-appwrite package. if ur project does not have them, it will give a error

    dependencies are what the package itself requires.

    this is why for peerDependencies there is an asterisk "*", means u can use any version of the dependency in your project. But for the appwrite package, we keep it restrictive so a breaking change in future doesnt automatically break the appwrite package.

  14. mi5ha commented on Mar 18, 2025

    @mi5ha
    Author

    @ChiragAgg5k Thanx for the article, its a good introduction into the subject! 😀 But we still have an issue with this package.json setup.

    First, having same dependency in 2 places is not recommended. "dependencies" has bigger priority so "react-native": "*" in peerDependencies is being ignored. No point of having it there. And having ^ for expo-file-system package would not hurt I think, because there should be no braking chages during major version updates.

    What to put in react-native version is tricky because major version is still 0, but I would still put ^ there, or > maybe.

    You say you are doing this because you want to protect from breaking changes in future. Which never happened until now right? 😀 But you are having real issue in the present, that will keep reappearing with each minor update of both react-native and expo-file-system.

    This last fix you made will fail in couple of weeks tops, thats what I am worried about 😊 That you will have ongoing maintenance burden with this. What do you say about just giving min versions?

    "peerDependencies": {
      "react-native": ">=0.70.0",
      "expo-file-system": ">=15.0.0"
    }
    
  15. ChiragAgg5k commented on Mar 18, 2025

    @ChiragAgg5k
    Member
    1. for peerDependencies, i am still a bit on edge if we need a min version, since we want that control over to the user. so let's keep it as:

      "peerDependencies": {
        "expo": "*"
      }

      we can remove react-native there as you suggested, and expo-file-system should not be in peerDependencies.

    2. What to put in react-native version is tricky because major version is still 0, but I would still put ^ there, or > maybe.

      there we can use a ~ symbol which would only allow patch versions.


    awesome work with all the suggestions @mi5ha 💪

    infact would you like to create a PR for this change? you can make the changes here - https://github.com/appwrite/sdk-generator/blob/master/templates/react-native/package.json.twig

  16. mi5ha commented on Mar 18, 2025

    @mi5ha
    Author

    @ChiragAgg5k Here is the PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions