Skip to content

Conversation

SinghaAnirban005
Copy link
Contributor

@SinghaAnirban005 SinghaAnirban005 commented Apr 4, 2025

React-Native project development fails

Acceptance Criteria fulfillment

  • Changed the version of the @embeddedchat/api package to use the latest one instead of the deprecated version
  • Ran yarn install at the root level
  • Hardcoded the api version inside the react-native repo

Reason I have hardcoded instead of using workspace:^

  1. While using workspace:^ works only on removing the yarn.lock file present inside the react-native repo, but doing this introduces dependency issues
  2. The Metro bundler can't properly resolve the local dependency paths
  3. Hence harcoding the version of api package inside the react-native repo is the best workaround to have for now

Fixes #1000

Video/Screenshots

2025-04-04.23-49-34.mp4

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.

@Spiral-Memory
Copy link
Collaborator

Hi @SinghaAnirban005
Thanks for this PR

Why it is showing these many changes ?

@Spiral-Memory
Copy link
Collaborator

Can you please ignore those yarn cache files

@Spiral-Memory
Copy link
Collaborator

Hi @SinghaAnirban005
Any idea, why yarn.lock is getting affected this much with just one version change

@SinghaAnirban005
Copy link
Contributor Author

SinghaAnirban005 commented Apr 5, 2025

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
Copy link
Collaborator

Sure, meanwhile I'm approving it

@SinghaAnirban005
Copy link
Contributor Author

@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:^ :

  1. 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.

  2. 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

@Spiral-Memory
Copy link
Collaborator

Then do one think, delete that, run yarn, to get a new lock file and then we can have that

Will that work ?

@SinghaAnirban005
Copy link
Contributor Author

SinghaAnirban005 commented Apr 5, 2025

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

@abirc8010
Copy link
Contributor

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.

@SinghaAnirban005
Copy link
Contributor Author

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

@Spiral-Memory
Copy link
Collaborator

Spiral-Memory commented May 24, 2025

@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

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Version Mismatch: @embeddedchat/api Not Recognized in Monorepo Workspace

3 participants