resolveConfig(cwd) fails to find config file

[mbeckem]

Environments:

• Prettier Version: 3.1.1
• Running Prettier via: Node
• Runtime: Node 18
• Operating System: Linux
• Prettier plugins (if any): None

Steps to reproduce:

1. Open https://stackblitz.com/edit/node-37bnjb?file=test.js
2. Run node ./test.js

Expected behavior:

The script prints the parsed contents of the .prettierrc inside that directory, since cwd is an explicitly supported input parameter (see https://prettier.io/docs/en/api.html#prettierresolveconfigfileurlorpath--options)

Actual behavior:

The script prints null.

Notes:

• Downgrade prettier to version 2 by editing the package.json followed by running npm install.
  • node ./test.js will print the expected output
• The resolveConfig function in prettier v3 appears to start its search in dirname(cwd) instead of cwd, thus never testing for the existence of .prettierrc in the project directory.

[fisker]

Broken by #15363, didn't know it's documented, I thought it's bug..

[fisker]

Maybe we can restore the old behavior, and add a new .resolveConfigForFile()?

[fisker]

It's really bad that it accepts a dir path, which make no sense at all. Config files can have overrides, without file path the resolved config can be totally wrong.

[mbeckem]

I agree that always passing the path to the actual file would be the best approach moving forward. However, this is a pretty hard break in documented behavior. Is it possible restore (but deprecate) the old behavior for compatibilty and include a warning in the docs, so the old behavior can be removed at a later time? There might be other tools that rely on the old directory lookup.

[fisker]

Is it possible restore (but deprecate) the old behavior for compatibilty and include a warning in the docs, so the old behavior can be removed at a later time?

I agree this is reasonable, but we'll have to add another usable/correct api, and it will be hard (and take a long time) to remove the new added one again. I highly doubt there are more broken cases.

I say, we should just update the docs to reflect the current behavior.

@sosukesuzuki need your opinion.

[sosukesuzuki]

@fisker I agree with you. It is enough to update the docs I think. If the same problem is reported repeatedly in the future, we can consider again.

[fisker]

Would you like to update it?

[sosukesuzuki]

If you can do it, I want you to do it.

[fisker]

Going to sleep..maybe later.

[sosukesuzuki]

@fisker If we should just update the documentation, can we remove this from 3.2 milestone?