RocketChat
fix: React-Native project fails to load up during development
React-Native project development fails
Acceptance Criteria fulfillment
- [x] Changed the version of the @embeddedchat/api package to use the latest one instead of the deprecated version
- [x] Ran yarn install at the root level
- [x] Hardcoded the api version inside the react-native repo
Reason I have hardcoded instead of using workspace:^
- While using workspace:^ works only on removing the yarn.lock file present inside the react-native repo, but doing this introduces dependency issues
- The Metro bundler can't properly resolve the local dependency paths
- Hence harcoding the version of api package inside the react-native repo is the best workaround to have for now
Fixes #1000
Video/Screenshots
https://github.com/user-attachments/assets/f2c64154-b2d2-43bc-b053-1e990411c82e
PR Test Details
Note: The PR will be ready for live testing at https://rocketchat.github.io/EmbeddedChat/pulls/pr-1001 after approval. Contributors are requested to replace <pr_number> with the actual PR number.
Hi @SinghaAnirban005 Thanks for this PR
Why it is showing these many changes ?
Hi @SinghaAnirban005 Any idea, why yarn.lock is getting affected this much with just one version change
Might be because of including a new library in the react-native package !! I shall investigate further and then let you know @Spiral-Memory
@Spiral-Memory The reason for such large number of additions accounts to the hardcoding of the version for @embeddedchat/api in the react-native project . Due to which all the dependencies were installed separately, even if they exist already in the root or other package.
This can be tackled by using workspace:^ instead of hardcoding version number . Due to hardcoding version number it was searching for the api package in the npm registry
But few considerations before using workspace:^ :
-
On running yarn I ran into an issue where Yarn couldn’t resolve the workspace version and threw an error like could not find workspace:^. After digging in, I found that this was caused by the presence of an existing yarn.lock file inside packages/react-native. This lockfile caused Yarn to treat it as an external package instead of linking the local workspace version.
-
To resolve this i removed the old yarn.lock file and ran yarn install . After that, things worked as expected.
So the solution given in the PR can be thought of as a temporary workaround . I didn't want to delete the existing yarn.lock file so i had to come up with the given solution
Then do one think, delete that, run yarn, to get a new lock file and then we can have that
Will that work ?
deleting the yarn.lock file inside the native repo and then running a yarn install wont generate a new lockfile since it is treated as a yarn workspace
i believe there should be only a central lockfile for this monorepo at the root level
While using workspace:^ works only on removing the yarn.lock file present inside the react-native repo, but doing this introduces dependency issues
I’ve tested this as well. Using workspace:^ in embeddedchat/api leads to dependency issues, unless the expo package is installed at the root level. Additionally, to make it compatible, some more React Native specific packages also need to be added to the monorepo’s dependencies.
Absolutely ! I felt that this issue can be solved more comprehensively during the Gsoc period since it involves upgrading and importing of few packages (aligns with the deliverables in the Emb chat 2025) hence my solution was just to provide a temporary workaround for few contributors who were complaining about this issue. I have confirmed with Zishan that this particular issue can later be handled more gracefully by whoever is selected for this project . Thank You
@SinghaAnirban005 @abirc8010 @devanshkansagra If anyone of you is available, look into it and see if we can atleast make that mobile app in a working condition atleast with minimal changes. Thanks