Add support for Yarn 2 / Yarn 3

[kayb-proxora]

Hello,

Is it possible to use yarn 2 with the plugin?

In normal yarn 2 setup you have to enable yarn 2 via:
yarn set version berry

Is there a way to also do this with the plugin?

Thanks & regards,

Kay

[deepy]

Up to this point I thought that yarn was the sane alternative to npm, but the way to change to yarn 2 is bizarre.

I haven't tested this myself, but I think something like this might work:

def setVersion = tasks.register(yarnSetVersion, YarnTask) {
    args = ['set', 'version', 'berry']
}

tasks.named('yarnSetup').configure { finalizedBy setVersion }

You might have to run the yarnSetVersion task once manually

[kayb-proxora]

Thanks for the quick feedback. I tried your suggestion, but it seems that the install task is not triggered now:

Internal Error: react-frontend@workspace:.: This package doesn't seem to be present in your lockfile; try to make an install to update your resolutions
    at J.getCandidates (\react-frontend\.yarn\releases\yarn-2.4.2.cjs:2:353956)
    at n.getCandidates (\react-frontend\.yarn\releases\yarn-2.4.2.cjs:2:342946)
    at \react-frontend\.yarn\releases\yarn-2.4.2.cjs:2:364602
    at Module.w (\react-frontend\.yarn\releases\yarn-2.4.2.cjs:2:424073)
    at C (\react-frontend\.yarn\releases\yarn-2.4.2.cjs:2:364565)

Yarn 2 is also generating different files. It creates a .yarn folder and a .yarnrc.yml file. Maybe the plugin has to handle yarn 2 differently?

[deepy]

yeah it sounds like we're going to have to look into how we can support yarn 2.
but their setup seems pretty bizarre to me, I don't understand why they wouldn't either set the version to 2 for yarn 2 or create a yarn2 package if they absolutely need them to be separate and installed at the same time

[kayb-proxora]

Yes, I agree. The way to use yarn 2 is very strange.

Would be great if you can support yarn 2 in a future release. :)

[boris-petrov]

For starters, Yarn 2 support with the backwards-compatible nodeLinker option could be implemented. As you see from the migration guide, it should be pretty straight-forward to migrate to Yarn 2 in this way (i.e. not using the new PnP mechanisms). And, according to people on the web, it's time to migrate to Yarn 2. :) So it would be nice to support this.

[xenoterracide]

hmm, +1 though I would prefer the ability to use PnP though this doesn't seem like it should be hard?

[boris-petrov]

So there is Yarn 3 already. I can't seem to keep up with these releases. 😃 Has anyone tried that with gradle-node-plugin?

[ericparton]

So I have some good news; if you run that weird yarn set version command, it very explicitly says exactly what it's doing:

YN0000: Retrieving https://repo.yarnpkg.com/3.1.0/packages/yarnpkg-cli/bin/yarn.js
YN0000: Saving the new release in .yarn/releases/yarn-3.1.0.cjs 

If that's all that's necessary, it should be possible to replicate those two steps in the plugin

[strawberry-choco]

Any updates on this? Yarn 3 is extremely awesome, and we would love to use it. :)

[hoanvh]

I'm using Yarn 3 with this plugin already, without any problem until now:

plugins {
    id 'com.github.node-gradle.node' version '3.5.0'
}

node {
    download = true
    version = '16.18.1'         // NodeJS version
    yarnVersion = '1.22.19'     // Yarn 1 version, we will upgrade to Yarn 3 later
}

task yarnUpgrade(type: YarnTask, dependsOn: 'yarnSetup') {
    args = ['set', 'version', 'stable']     // maybe with `yarn set version 3.x` also
}

task yarnInstall(type: YarnTask, dependsOn: 'yarnUpgrade') {
    args = ['install', '--immutable']
}

task yarnBuild(type: YarnTask, dependsOn: 'yarnInstall') {
    args = ['run', 'build', "--mode=${project.getProperties().getOrDefault("mode", "local")}"]
    environment = [
            BUILD_VERSION: project.version,
            BUILD_TIME: "${System.currentTimeMillis()}",
    ]
}

task build(dependsOn: 'yarnBuild') {
    //
}

[strawberry-choco]

Yes, correct. It works, but not nice since we are relying on yarn 1 itself. Can't we have native yarn berry support?

[muenchto]

Hi @hoanvh ,
thanks for this possible solution. However, now I have the problem that yarn 2+ will actually upgrade my dependencies in the yarn.lock, within the ranges defined in the package.lock (like ^1.0.2). Consequently, this will cause failure because of the --immutable argument, that you rightfully pass in your example.
Do you have any solution for this problem?

What is strange, that the checked-in yarn.lock was already created with yarn 2+ locally. So why is the yarn 2+ inside the gradle plugin not respecting this existing valid yarn.lock?

Thanks in advance!

[hoanvh]

--immutable flag makes sure that the installation from Yarn will not change our dependencies (name, version, ...).
In my case, whenever there is a failure causing by --immutable, I will install packages without that flag first, review the new version and commit it (package.lock / yarn.lock).
In your case, I guess the version of yarn 2+ before & after does not match.
Inside lock file, some of packages will be updated whenever there is a new version of Yarn.
In my case, I use typescript package, and even I'm using a fixed version, its commit hash will always be changed, whenever I upgrade Yarn version (by yarn set version stable command). And it's normal.