Maël Nison

I'd suggest to disable auto-pinning before tagging 1.0 stable.

> Is there any likelihood that Corepack will ever achieve a `1.0.0` release status? I don't personnally see a benefit to bringing it to 1.0, and I don't see it...

> work towards deprecation announcement of corepack? No, since it's not deprecated. People will have to install it manually from npm for the time being, and it's possible that in...

> The closest file, such as `./package.json`, is generally the most relevant. Not really, no. The most typical case is to have a package.json inside a `node_modules`, in which case...

Can we instead make the error message clearer in the CLI itself? Perhaps by listing the path where the top-level project was found using the [`ReportError` API](https://github.com/yarnpkg/berry/blob/master/packages/yarnpkg-core/sources/httpUtils.ts#L73-L79)?

My understanding from a cursory glance is that you install the project in the HOME folder, so scripts evaluated with the `.js` extension (which seems to be the case for...

We're missing a [test](https://github.com/nodejs/corepack/blob/main/tests/Use.test.ts) on that, but if I remember correctly the intent is to update the closest package.json that contains a `packageManager` field, or the closest package.json otherwise.

I'm not sure I follow - the test case below seems to return the expected results (it updates the monorepo root, not the workspace directory). Do you get something else?...

I see - yes, adding an explicit `packageManager` would be my current recommendation. We perhaps could also have a `--here` flag, or similar, for special cases where the user really...

I'm working in a feature that should solve this in a more generic way (basically by allowing to write cross-workspaces constraints). It'll take some time, but I hope to release...