fix: improve flow in init command on higher Yarn versions

[szymonrybczak]

Summary:

Closes #1637
Closes #1912

This PR improves flow creating project when user has higher Yarn version.

Test Plan:

1. Clone the repository and do all the required steps from the Contributing guide.
2. Install yarn at version 2.x.x.
3. Run this command:

node /path/to/react-native-cli/packages/cli/build/bin.js init

It should ask to create .yarnrc.yml inside project or to use Yarn Classic.
4. Install yarn at version 3.x.x.
5. Run this command:

node /path/to/react-native-cli/packages/cli/build/bin.js init

It should detect your .yarnrc.yml and check what nodeLinker is specified. If it isn't node-modules, CLI should ask to change it.
6. Install yarn at version 1.x.x.
7. Run this command:

node /path/to/react-native-cli/packages/cli/build/bin.js init

It should create project correctly.

[kelset]

blocking for merging until the yarn v3 concern is addressed

[satya164]

The ideal approach would be to set the Yarn version in the project itself than relying on global Yarn. There being fundamental differences and breaking changes between the Yarn versions, this approach allows users to work on multiple projects needing different Yarn versions. This is also recommended workflow for Yarn >= 2 - if people want to use newer Yarn, then they need to run yarn set version berry.

However we can do similar for Yarn 1 too, something like: yarn set version 1. imo it'd best to settle on the Yarn version we support and adjust the template with appropriate config file and run yarn set version instead of using the globally installed version.

[szymonrybczak]

I would like to renew discussion under this pull request, because it is getting a little bit stale.

@satya164 Thanks for feedback! I think your point is very interesting, but it may be hard to implement. The current implementation is more flexible to me. I think we cannot specify Yarn version in template, and we actually don't know what version user wants to use because it depends on preferences, what Yarn version project is using etc.
Right now we detect Yarn version by doing yarn -v, and if the version is >= 2 we're checking what nodeLinker they have in .yarnrnc.yml and we tell them to use nodeLinker: node-modules. With that we don't care what Yarn version user is using, we only care about nodeLinker because this is important for us. If the nodeLiner is not node-modules project cannot be initialised correctly.

[satya164]

I think your point is very interesting, but it may be hard to implement

Why is it hard to implement? It's just running one command one in the project. It is also recommended workflow for Yarn 2.

We can add nodeLinker to the config based on Yarn version, but if we want to properly support Yarn 2/3, we should also follow all the recommended setup, such as proper gitignore entries, setting version in package.json etc. https://yarnpkg.com/getting-started/migration#step-by-step

we actually don't know what version user wants to use because it depends on preferences

IMO trying to support multiple versions of Yarn means more effort maintaining it. is there a reason anyone actually would want to stay on old version of Yarn? I have only seen people stay on Yarn 1 because they thought that Yarn >= 2 doesn't work with React Native.

[szymonrybczak]

After some internal discussion with @satya164, we came to conclusion that actually it would be better and easier in long term to provide default Yarn version in React Native template, but are there any blockers from providing default Yarn version >=2 (of course with nodeLinker: node-modules) in template? cc. @kelset @cortinico

[tido64]

After some internal discussion with @satya164, we came to conclusion that actually it would be better and easier in long term to provide default Yarn version in React Native template, but are there any blockers from providing default Yarn version >=2 (of course with nodeLinker: node-modules) in template? cc. @kelset @cortinico

Not quite a blocker, but can still be annoying, is that Yarn >= 2 always patches TypeScript, regardless of whether you use PnP. This might break if your TypeScript version is ahead. If we really are going down this path, I would recommend v3 over v2.

[github-actions]

There hasn't been any activity on this pull request in the past 3 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.

[github-actions]

There hasn't been any activity on this pull request in the past 3 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.