Missing yarn.lock from the init repo breaks Yarn installs

[arcanis]

Description

The following commit removed the yarn.lock from gatsby-starter-default:

gatsbyjs/gatsby-starter-default@a5368fa#diff-51e4f558fae534656963876761c95b83b6ef5da5103c4adef6768219ed76c2de

As a result, the init script now goes through the following codepath:

gatsby/packages/gatsby-cli/src/init-starter.ts

Lines 113 to 119 in b22384c

	if (getPackageManager() === `yarn` && checkForYarn()) {
	if (await fs.pathExists(`package-lock.json`)) {
	if (!(await fs.pathExists(`yarn.lock`))) {
	await spawn(`yarnpkg import`)
	}
	await fs.remove(`package-lock.json`)
	}

The yarn import command has been deprecated / removed in Yarn 2, and crashes.

Steps to reproduce

cd $(mktemp -d)
yarn init -2 -w
yarn dlx gatsby new my-gatsby

Expected result

Works

Actual result

Breaks

[arcanis]

Seems to have broke starting from #26856, cc @laurieontech

[gillkyle]

Thanks for reporting this bug!

I was able to reproduce and will provide some ideas, though probably need @laurieontech's feedback on the why of the lock files removal. My understanding is that the deprecation of yarn import is what is causing this to break, and the missing yarn.lock files is just what is causing this code to get to those declarations, does that seem like a fair assessment @arcanis?

Here's my output running: npx yarn@berry dlx gatsby new my-gatsby-3

Erroneous output

info Creating new site from git: https://github.com/gatsbyjs/gatsby-starter-default.git
Cloning into 'my-gatsby-3'...
remote: Enumerating objects: 28, done.
remote: Counting objects: 100% (28/28), done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 28 (delta 2), reused 13 (delta 0), pack-reused 0
Unpacking objects: 100% (28/28), done.
success Created starter directory layout
info Installing packages...
Usage Error: The nearest package directory (/Users/kyle/tmp/issue28238/my-gatsby-3) doesn't seem to be part of the project declared in /Users/kyle/tmp/issue28238.

- If the project directory is right, it might be that you forgot to list my-gatsby-3 as a workspace.
- If it isn't, it's likely because you have a yarn.lock or package.json file there, confusing the project root detection.

$ yarn run [--inspect] [--inspect-brk]  ...
error Command failed with exit code 1: yarnpkg import


  Error: Command failed with exit code 1: yarnpkg import

  - error.js:56 makeError
    [lib]/[gatsby-cli]/[execa]/lib/error.js:56:11

  - index.js:114 handlePromise
    [lib]/[gatsby-cli]/[execa]/index.js:114:26

  - task_queues.js:97 processTicksAndRejections
    internal/process/task_queues.js:97:5

  - init-starter.js:133 install
    [lib]/[gatsby-cli]/lib/init-starter.js:133:11

  - init-starter.js:209 clone
    [lib]/[gatsby-cli]/lib/init-starter.js:209:3

  - init-starter.js:350 initStarter
    [lib]/[gatsby-cli]/lib/init-starter.js:350:5

  - create-cli.js:443
    [lib]/[gatsby-cli]/lib/create-cli.js:443:7

The key part being: error Command failed with exit code 1: yarnpkg import

Since Yarn Modern removes that command, I'm wondering if we can just skip that invocation entirely for Yarn Modern (or maybe just entirely) and generate the lock file from when yarn is called below it?

[arcanis]

My understanding is that the deprecation of yarn import is what is causing this to break, and the missing yarn.lock files is just what is causing this code to get to those declarations, does that seem like a fair assessment @arcanis?

Not quite; due to both architectural differences between our package managers and the complexity of keeping the command forward-compatible with future npm versions, running yarn import as part of a classic project bootstrap is not a recommended practice regardless of the context.

My understanding is that the code behaved this way to have low-cost best-effort compatibility with templates that didn't use Yarn; running this option should only be seen as a last resort option, and frankly I feel it'd be better to have no import than try to auto-import an npm one.

Since Yarn Modern removes that command, I'm wondering if we can just skip that invocation entirely for Yarn Modern (or maybe just entirely) and generate the lock file from when yarn is called below it?

That's fine by me, although it's too bad the perfs will be made worse on Yarn because of the drop of the lockfile. What's the reason for removing it in the first place?

[mxstbr]

What's the reason for removing it in the first place?

We want users to get the latest versions of the dependencies that match the semver version from package.json, not the versions specified in the lockfile!

[merceyz]

If that's the case shouldn't package-lock.json have been deleted as well?

[ascorbic]

My understanding was that we were only removing it from the minimal starter because it was targetting a canary, and with that we were removing both lockfiles. I don't know why we'd remove it from others.