test: resolve configs when `--stdin-filepath` is used by pralkarz · Pull Request #58 · prettier/prettier-cli

pralkarz · 2025-04-22T22:19:16Z

Based on #52.

TODOs:

Prettier v3 seems to remove semicolons for some reason, v4 doesn't, need to investigate that
handling for Prettier configs
handling for ignore files
false positive tests

Copies the stdin-filepath tests from prettier. Notable differences: - Blocked by #21 - Syntax errors output the `stdin-filepath` basename in prettier but not in this CLI (e.g. `[Error] foo.js SyntaxError blah`)

src/config_editorconfig.ts

pralkarz · 2025-04-23T07:34:03Z

src/config_editorconfig.ts

    const fileName = filesNames[i];
    const filePath = fastJoinedPath(folderPath, fileName);
-    if (!Known.hasFilePath(filePath)) continue;
+    if (!ignoreKnown && !Known.hasFilePath(filePath)) continue;


Not a huge fan as ignoreKnown needs to be passed through multiple hoops before it ends up here, but I'm not sure how else we could solve this (getStdin doesn't populate Known, and so we'd always end up not reading any config).

I'm also not sure whether this impacts performance, i.e. the whole chain – not populating Known in runStdin and resolving the configs without it.

pralkarz · 2025-04-23T07:35:26Z

test/__fixtures__/editorconfig/.prettierrc

In Prettier v3, this file lives in a bigger overarching fixture directory (config), but it's needed for the snapshots to match what we expect. We could consider removing it, but then we need to update the snapshots to include semicolons.

pralkarz · 2025-04-23T07:36:57Z

test/__fixtures__/editorconfig/.prettierrc

@@ -0,0 +1,8 @@
+endOfLine: 'auto'
+overrides:
+- files: "**/*.js"


In Prettier v3, this is just "*.js", but a/a/a/a/a/a/three.js matches that there somehow (maybe they do some exploding to include the leading **?). Since we usually provide nested paths in --stdin-path, the overrides wouldn't apply without **/.

prettier treats *.ext as **/*.ext. not through any exploding/splitting, it just prepends it iirc

Is this something that we should do in v4 too or rather require the users to handle it explicitly?

there was a conversation a while back around it. im not sure if it was in discord or on here
but iirc, fisker's opinion was that it makes patterns easier to write (*.ts to format all ts files is easier than **/*.ts). even though it isn't the right glob

we should probably discuss it again and make a decision

pralkarz · 2025-04-23T07:49:54Z

test/__tests__/stdin-filepath.js

+// TODO: This is currently a false positive as no config actually gets resolved, but Prettier
+// somehow formats the input correctly anyway.
+describe("apply editorconfig for stdin-filepath in root", () => {
+  const code = dedent`
+    function f() {
+      console.log("should be indented with a tab");
+    }
+  `;
+  runCli("", ["--stdin-filepath", "/foo.js"], {
+    input: code, // js
+  }).test({
+    status: 0,
+    stdout: code,
+    stderr: "",
+    write: [],
+  });
+});


I'm not sure what we expect here. The test case's name implies that we should search for any .editorconfig (either starting from root or from CWD) and apply it (especially since this test is only ran in CI in v3), but it seems like an odd choice.

pralkarz · 2025-04-23T07:51:44Z

test/__tests__/stdin-filepath.js

+// TODO: This is currently a false positive. Gotta investigate how it's handled in Prettier v3 to
+// gauge the expected behavior.
+describe("don't apply editorconfig outside project for stdin-filepath with nonexistent directory", () => {
+  runCli(
+    "",
+    [
+      "--stdin-filepath",
+      "editorconfig/repo-root/nonexistent/one/two/three.js",
+    ],
+    {
+      input: dedent`
+        function f() {
+          console.log("should be indented with 2 spaces");
+        }
+      `, // js
+    },
+  ).test({
+    status: 0,
+  });
+});


It's currently a false positive, but when we change the first argument in runCli to editorconfig and update the path accordingly, stdin does get formatted based on __fixtures__/editorconfig/.editorconfig. Not sure why it wouldn't based on the other test cases. Maybe it's because repo-root counts as a separate project due to .hg there? Such an edge case could be quite tricky to support.

pralkarz · 2025-04-23T08:05:29Z

src/index.ts

+  const ignoreNames = options.ignore ? [".gitignore", ".prettierignore"] : [];
+  const isIgnored = await getIgnoreResolved(fileName, ignoreNames, true);
+  if (isIgnored) {
+    stdout.always(trimFinalNewline(fileContent));


This matches the v3 behavior based on the related test case, where the ignored file gets output as is.

pralkarz · 2025-04-23T08:07:23Z

src/index.ts

+  const ignoreNames = options.ignore ? [".gitignore", ".prettierignore"] : [];
+  const isIgnored = await getIgnoreResolved(fileName, ignoreNames, true);


The logic is a bit more involved in runGlobs, but we don't have a way to explicitly include a file when handling the stdin case, so it's quite simplified.

…stdin-filepath-test-fixes

43081j · 2025-05-06T20:59:47Z

src/index.ts


 async function run(options: Options, pluginsDefaultOptions: PluginsOptions, pluginsCustomOptions: PluginsOptions): Promise<void> {
-  if (options.globs.length || !isString(await getStdin())) {
+  if (options.globs.length || (!isString(await getStdin()) && !("stdinFilepath" in options))) {


can you explain this one?

if there is stdin and there is a stdinFilepath, we now runGlobs?

and if there's no stdin but there is a stdinFilepath, we'd also runGlobs?

unless im reading wrong, thats what its doing now

I based this branch on yours, you seem to have added this condition in 585f1be. Not really sure what the rationale was, but it seems to make sense, right? We runGlobs either when options.globs is not empty or there's no stdinFilepath in options AND there's no stdin data.

if there's no stdinFilePath but there is stdin, we'll now call runStdin i think?

so i probably got this condition wrong. i don't remember why i did it that way

if there's no stdin or there's globs, we should runGlobs. otherwise, we can runStdin

pralkarz · 2026-02-11T14:25:24Z

Closing as I won't have time to work on this in the near future.

pralkarz and others added 7 commits February 10, 2025 01:11

Ported test suite: patterns

6d71385

Merge 'upstream/main' into 'main'

fffaada

test: migrate stdin-filepath tests

585f1be

Copies the stdin-filepath tests from prettier. Notable differences: - Blocked by #21 - Syntax errors output the `stdin-filepath` basename in prettier but not in this CLI (e.g. `[Error] foo.js SyntaxError blah`)

Merge branch 'main' of https://github.com/pralkarz/prettier-cli

e66a9b5

Merge branch 'main' into stdin-filepath-test-fixes

c9533e7

test: add the progress so far

086c44c

chore: restore the private modifier

f1c2dc1

pralkarz commented Apr 22, 2025

View reviewed changes

src/config_editorconfig.ts Outdated Show resolved Hide resolved

pralkarz added 2 commits April 23, 2025 09:31

test: resolve Prettier configs

fd0e3b0

test: remove leftover .only

d5324f4

pralkarz commented Apr 23, 2025

View reviewed changes

test: resolve ignore files

ce18801

pralkarz commented Apr 23, 2025

View reviewed changes

pralkarz added 2 commits May 6, 2025 17:54

test: populate Known in runStdin

12698fe

Merge branch 'main' of https://github.com/prettier/prettier-cli into …

3581b43

…stdin-filepath-test-fixes

43081j reviewed May 6, 2025

View reviewed changes

pralkarz closed this Feb 11, 2026

		const ignoreNames = options.ignore ? [".gitignore", ".prettierignore"] : [];
		const isIgnored = await getIgnoreResolved(fileName, ignoreNames, true);

Uh oh!

Conversation

pralkarz commented Apr 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

pralkarz Apr 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pralkarz Apr 23, 2025

Choose a reason for hiding this comment

Uh oh!

pralkarz Apr 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

43081j Apr 23, 2025

Choose a reason for hiding this comment

Uh oh!

pralkarz Apr 23, 2025

Choose a reason for hiding this comment

Uh oh!

43081j Apr 23, 2025

Choose a reason for hiding this comment

Uh oh!

pralkarz Apr 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pralkarz Apr 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pralkarz Apr 23, 2025

Choose a reason for hiding this comment

Uh oh!

pralkarz Apr 23, 2025

Choose a reason for hiding this comment

Uh oh!

43081j May 6, 2025

Choose a reason for hiding this comment

Uh oh!

pralkarz May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

43081j May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pralkarz commented Feb 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

pralkarz commented Apr 22, 2025 •

edited

Loading

pralkarz Apr 23, 2025 •

edited

Loading

pralkarz Apr 23, 2025 •

edited

Loading

pralkarz Apr 23, 2025 •

edited

Loading

pralkarz Apr 23, 2025 •

edited

Loading

pralkarz May 7, 2025 •

edited

Loading

43081j May 7, 2025 •

edited

Loading