gradle-node-plugin icon indicating copy to clipboard operation
gradle-node-plugin copied to clipboard

Allow use of corepack to provision yarn, etc.

Open megla-tlanghorst opened this issue 2 weeks ago • 2 comments

Nowadays the proper way to provision package managers is corepack as the package manager version is codified in the package.json. Some package managers even refuse to launch when another is set up, especially if they are set up by corepack themselves: This project is configured to use yarn because package.json has a "packageManager" field

You can work around it currently by just setting it up like the following, but it's a bit clunky;

val isWindows = providers.systemProperty("os.name").map { it.contains("windows", true) }

node {
    yarnCommand = layout.buildDirectory.dir("corepack").flatMap { dir ->
        isWindows.map {
            if (it) {
                dir.file("yarn.CMD")
            } else {
                dir.file("yarn")
            }.toString()
        }
    }
}

val corepackSetup = tasks.register<NpxTask>("corepackSetup") {
    command = "corepack@latest"

    val corepackInstallDir = layout.buildDirectory.dir("corepack")
    args.set(corepackInstallDir.map { listOf("enable", "--install-directory", it.asFile.absolutePath) })
    outputs.dir(corepackInstallDir)
}

tasks.yarnSetup {
    dependsOn(corepackSetup)
    enabled = false
}

corepack is just shipped by default with current node versions and for older ones and for older version npx should just download it.

This help to properly use the correct package manager version and in general works a lot simpler than any other setup. COREPACK_HOME can be set to control where it downloads the package managers to as well, if needed. The version can of course also be set using npx or it could probably be manually downloaded like yarn or npm currently are.

Alternatively the plugin could try to parse the packageManager field itself, but not sure if that makes a lot of sense.

megla-tlanghorst avatar Nov 11 '25 23:11 megla-tlanghorst

corepack looks to be distributed with all the current LTS versions, but also from what I can tell they're dropping it in the newest version (25) https://nodejs.org/dist/v25.2.0/docs/api/corepack.html Which is kinda sad because it looked like a pretty good fit 🥲

This would require an intermediate task, but I'm not sure if "download node -> download npm -> run npm install" is significantly different to "download node -> make corepack download npm -> run npm install" Although it'd be very tempting to simplify everything to "download node -> run corepack npm install", but then the codebase would need to split again

Regardless there's some extra investigations to be done, and to keep the bun support (that hasn't been released yet) we'd probably need to parse packageManager But it's also very tempting to get proper support for yarn versions newer than 1.x

deepy avatar Nov 12 '25 09:11 deepy

Regardless there's some extra investigations to be done, and to keep the bun support (that hasn't been released yet) we'd probably need to parse packageManager But it's also very tempting to get proper support for yarn versions newer than 1.x

It could maybe just be a flag or something.

corepack looks to be distributed with all the current LTS versions, but also from what I can tell they're dropping it in the newest version (25) https://nodejs.org/dist/v25.2.0/docs/api/corepack.html Which is kinda sad because it looked like a pretty good fit 🥲

I've had issues with the distributed corepack not properly setting up the scripot in linux anyway, so I let npx download a newer version, if added properly to this plugin, it might be best to just download it directly from their repo: https://github.com/nodejs/corepack/releases/download/v0.34.3/corepack.tgz. From there you'd just need to call the corepack.js or you may de able to just directly call yarn.js from their dist folder.

megla-tlanghorst avatar Nov 12 '25 09:11 megla-tlanghorst