add resolveConfigWithFilePath API

[SavePointSam]

This PR introduces a new API prettier.resolveConfigWithFilePath. This method uses the pre-existing internals to find and merge prettier configurations, but exposes the resolved file path for consumers. This will close #3451 and allow us to solve prettier/prettier-atom#270.

I also reorganized the API docs a bit so that similar API sit next to each other.

[azz]

What if we just had resolveConfig return the path, too:

prettier.resolveConfig.sync('some/path.js');
// -> 
//    {
//      useTabs: true,
//      configPath: "/abs/path/.prettierrc"
//    }

[SavePointSam]

That's also an option, however I would suggest against it. It makes sense that the API returns the configuration as Prettier can later ingest it. Adding extra properties in this one case doesn't quite make sense to me and feels like a mix of concerns. Even more so when the rest of the time we are working with the configuration payload it is separated between config and filePath.

[j-f1]

Can this just be if (includeFilePath)?

[SavePointSam]

fixed!

[josephfrazier]

I'd suggest the following changes:

The response will include both the configuration that was resolved, along with the file path to the configuration file that was used to generate the configuration

However, it will not include the path to the located any .editorconfig file when used, as the core Prettier configuration configuration file acts as an override.

(note the , after used)

[josephfrazier]

...wait a minute. Couldn't we just export resolveConfigFile from src/config/resolve-config.js and index.js, instead of adding a separate function?

After typing this out, I realized that the use case (editor integrations) will likely want both the config and the file path anyway, so it probably makes sense to combine them into a single function, instead of forcing the integration to call two functions (which would also unnecessarily repeat the path resolution). I'm going to leave this comment here anyway, for the record.

[SavePointSam]

I thought the same thing at first. Though as someone who would be implementing this type of functionality, I'd much rather make a call that returns both the resolved/merged config as well as the file path of the config used. There is room for error when using those API separately.

[olsonpm]

I believe a valid workaround until this is resolved would be to use cosmiconfig's load directly. Anyway, I'm planning on using that to address "Show which options are used on format".

[azz]

Is there a way to expose the path to the editorconfig file too?

[josephfrazier]

I don't think https://github.com/editorconfig/editorconfig-core-js provides a way to see the path of the files being parsed (note that there can be more than one). However, assuming there's just one, we could use some combination of find-up and find-project-root to locate it. See also #3559

[olsonpm]

"assuming just one" could produce false positives though the simplification would be nice. Seems the devs behind editorconfig-core-js are pretty responsive though, so a PR adding a method such as this one wouldn't be out of the question.

[SavePointSam]

Sorry for the silence! Having some crunch time at the office :(

I totally agree we should find a way to expose the path to .editorconfig. Can it actually pick up multiple to merge together? That's pretty rough..

[olsonpm]

Bummer about the office time. I'm in between jobs so I finally get to work on stuff I enjoy haha.

Can it actually pick up multiple to merge together?

Unfortunately. I created a quick repo if you wanted to mess around with it.

[duailibe]

FTR resolveConfigFile was added #4364

[suchipi]

I'm going to close this based on #3846 (comment)