[Bug] Lock file in custom path (.yarn/lock.yml) causes doctor to crash

[stylemistake]

• I'd be willing to implement a fix

Describe the bug

Well, since yarnrc allows moving the lock file to arbitrary locations, it seemed like a good idea to move it to .yarn folder to keep the root directory one file cleaner.

But not all tools like this new path, and namely @yarnpkg/doctor fails with the following:

➤ YN0001: Error: ENOENT: no such file or directory, open 'C:\Users\style\AppData\Local\Temp\xfs-44fc7c45\dlx-13644\.yarn\lock.yml'
➤ YN0000: Failed with errors in 1s 484ms

To Reproduce

Reproduction

Shell

mv yarn.lock .yarn/lock.yml
echo "lockfileFilename: .yarn/lock.yml" >> .yarnrc.yml
yarn dlx @yarnpkg/doctor

Sherlock

const { promises: fs } = require('fs');

await fs.writeFile('.yarnrc.yml', 'lockfileFilename: .yarn/lock.yml', {
    encoding: 'utf-8',
});

await packageJsonAndInstall({});

const output = yarn('dlx', '@yarnpkg/doctor');
await expect(output).resolves.not.toContain('ENOENT');

[yarnbot]

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟

[yarnbot]

The reproduction case in your issue seems broken (ie it neither pass nor fail due to throwing an unmanaged exception):

Error: Command failed: /usr/bin/node /github/workspace/scripts/actions/../run-yarn.js install

➤ YN0028: The lockfile would have been created by this install, which is explicitly forbidden.
➤ YN0000: Failed with errors in 0s 3ms

    at ChildProcess.exithandler (child_process.js:308:12)
    at ChildProcess.emit (events.js:315:20)
    at maybeClose (internal/child_process.js:1048:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)

Remember: any non-Jest exceptions will cause the test to be reported as broken. If you expect something to pass without throwing, you must wrap it into something like await expect(...).resolves.toBeTruthy(). If you instead expect something to throw, you need to wrap it into await expect(...).rejects.toThrow().

[yarnbot]

The reproduction case in your issue seems broken (ie it neither pass nor fail due to throwing an unmanaged exception):

Error: Command failed: /usr/bin/node /github/workspace/scripts/actions/../run-yarn.js install

➤ YN0028: The lockfile would have been created by this install, which is explicitly forbidden.
➤ YN0000: Failed with errors in 0s 4ms

    at ChildProcess.exithandler (child_process.js:308:12)
    at ChildProcess.emit (events.js:315:20)
    at maybeClose (internal/child_process.js:1048:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)

Remember: any non-Jest exceptions will cause the test to be reported as broken. If you expect something to pass without throwing, you must wrap it into something like await expect(...).resolves.toBeTruthy(). If you instead expect something to throw, you need to wrap it into await expect(...).rejects.toThrow().

[yarnbot]

The reproduction case in your issue seems broken (ie it neither pass nor fail due to throwing an unmanaged exception):

Error: Command failed: /usr/bin/node /github/workspace/scripts/actions/../run-yarn.js install

➤ YN0028: The lockfile would have been created by this install, which is explicitly forbidden.
➤ YN0000: Failed with errors in 0s 4ms

    at ChildProcess.exithandler (child_process.js:308:12)
    at ChildProcess.emit (events.js:315:20)
    at maybeClose (internal/child_process.js:1048:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)

Remember: any non-Jest exceptions will cause the test to be reported as broken. If you expect something to pass without throwing, you must wrap it into something like await expect(...).resolves.toBeTruthy(). If you instead expect something to throw, you need to wrap it into await expect(...).rejects.toThrow().

[yarnbot]

The reproduction case in your issue seems broken (ie it neither pass nor fail due to throwing an unmanaged exception):

Error: Command failed: /usr/bin/node /github/workspace/scripts/actions/../run-yarn.js install

➤ YN0028: The lockfile would have been created by this install, which is explicitly forbidden.
➤ YN0000: Failed with errors in 0s 4ms

    at ChildProcess.exithandler (child_process.js:308:12)
    at ChildProcess.emit (events.js:315:20)
    at maybeClose (internal/child_process.js:1048:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)

Remember: any non-Jest exceptions will cause the test to be reported as broken. If you expect something to pass without throwing, you must wrap it into something like await expect(...).resolves.toBeTruthy(). If you instead expect something to throw, you need to wrap it into await expect(...).rejects.toThrow().

[yarnbot]

We couldn't reproduce your issue (all the assertions passed on master).

[stylemistake]

It works on my machine ¯\_(ツ)_/¯, but fuck it. I just wanted nice aesthetics 😔.

arcanis: I'd advise against it - it may work for Yarn (but again, I think we've started to hardcode it here and there), but third-party tools definitely won't support other locations that yarn.lock