Best Yarn Workspaces configuration to work with React Native for Windows Autolinking?

[kpete2017]

Currently, we already use Yarn Workspaces in tandem with RNFW and have recently gotten to the point where we are running into an issue with auto-linking. For example, let's say I have a local package that contains an RNFW native module called Example. When we then install that dependency in our main App and run npx react-native autolink-windows it will add the project accordingly in the .sln file

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Example", "......\packages\example\windows\Example\Example.csproj", "{97710FFB-45FB-49E8-89D0-FBB2003531DD}"
EndProject

This works fine, the problem arises when we want to use an older version of our library and pull it from our ADO registry. Yarn Workspaces will install this dependency in the App's local node_modules folder instead of hoisting it to the root node_modules which will cause two paths to the same project to appear when auto-linking is run again.

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Example", "......\packages\example\windows\Example\Example.csproj", "{97710FFB-45FB-49E8-89D0-FBB2003531DD}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Example", "..\node_modules\example\windows\Example\Example.csproj", "{97710FFB-45FB-49E8-89D0-FBB2003531DD}"
EndProject

This will cause build errors in either VS or running the run windows script. Although it's a pretty simple fix to just remove the duplicate entry manually, we run into this problem when we want to run pipeline builds that use older versions of our libraries such as production as well where we can't make manual changes.

We have thought of setting the react-native.config.js file to point auto-linking towards always using the mono repo's root node_modules version but this version is always the local package meaning we still are not getting our older remote package version. The App's node_modules folder may or may not contain the version we are looking for as well depending on whether it had downloaded that version or not so we cannot always point autolinking in that direction either.

With this in mind are there any configurations for either yarn workspaces or RNFW to mitigate this problem? All I can think of right now is to completely no-hoist the app itself and make sure all project paths point to the app's local node_modules folder but then we lose the benefits of being within a mono repo in the first place.

[jonthysell]

What version of RNW are you using? This scenario (where autolinked modules paths change) was fixed in RNW 0.70: ec96f99

[kpete2017]

We are currently using 0.67.14 actually. This seems very useful, thank you!

[jonthysell]

Okay, yeah, RN core updates pretty often and 0.67 is not supported anymore. See https://microsoft.github.io/react-native-windows/support for RNW support timelines.