Resolved files aren't globally sorted anymore. Instead, their order matches the order of the given patterns, and for each pattern, the corresponding group of files is sorted. This seems logical and acceptable while ditching the global sorting allows us to use generators to avoid various problems related to big arrays.

Open problems:

1. files found by globs but all ignored by .prettierignore - warning?
2. directory expanding + --parser: what is "supported files" then?
3. directory expanding + glob-based config overrides: same question

I guess only problem is how to get supported files in dir?

@thorn0

Can you also post a log run ./bin/prettier.js . on codebase?

What are the answers to the open problems?

Open problems:

1. files found by globs but all ignored by .prettierignore - warning?
2. directory expanding + --parser: what is "supported files" then?
3. directory expanding + glob-based config overrides: same question

What are the answers to the open problems?

# 2 and # 3 are the same problem, parser inference vs using extensions.

As for # 1, Prettier 1.19.1 doesn't issue any warning if passed a glob that is fully ignored by .prettierignore. Maybe it's not a big deal if the same happens with directories.

@thorn0

directory expanding + --parser: what is "supported files" then?

Maybe we should using only parser extensions for better DX and 0cjs

@evilebottnawi

directory expanding + --parser: what is "supported files" then?

Maybe we should using only parser extensions for better DX and 0cjs

I'd rather expect that prettier dir --parser html would match dir/**/* and use html for all files.

@fisker

glob all files from dir and yield {file, ignoreNoParserError: true} , deal with it later in handleError. This can handle unknown files add by config overrides. It seems if we do this, the NoResultsError also need move there, I didn't think about this before.

Yes. It's tricky. Not super difficult, but I'm sure that if I really start digging into it, I'll discover a dozen of new microissues there, so it might take long. The .prettierignore part looks especially suspicious. You tried to update the ignore package, so you should have an idea of what I mean.

I'd rather expect that prettier dir --parser html would match dir/**/* and use html for all files.

Yes, i think you are right. Do we have a test for this?

I'd rather expect that prettier dir --parser html would match dir/**/* and use html for all files.

This should work exactly if we used dir/**/*, so you're right. It should just follow the current precedence order: command line args / config via API, config file (overrides and whatnot), inference based on extension.

IMO these things shouldn't block this PR if these problems already existed when using a blob, but those problems were things I wished to fix for a very long time (that would end up being a 2.0 release), that are way more important than other things people are more concerned with 😅

I'd rather expect that prettier dir --parser html would match dir/**/* and use html for all files.

Yes, i think you are right. Do we have a test for this?

That's not how it works now. It's the same issue, namely: what exactly is "supported files" when we're searching for all "supported files" in a directory?

The current implementation in this PR: "supported files" = files with extensions and names taken from getSupportInfo().

An ideal implementation: "supported files" = glob(dir + '/**').filter(parserCanBeInferred). In the case when --parser is specified as a CLI arg, parserCanBeInferred turns into () => true.

Ah, now I understand the problem

The current implementation in this PR: "supported files" = files with extensions and names taken from getSupportInfo().

This sounds good to me

My proposal is to postpone the ideal implementation until 3.0.

My proposal is to postpone the ideal implementation until 3.0.

Sounds good for me, we will also collect feedback and it will help us make it better

Looks like @duailibe and @evilebottnawi both Okay with current implementation, I'm ok with it too.

But I have a question, can we somehow hide this NoParserError for both dir and glob? I'm on cellphone, I don't know how ESLint handle eslint foo.js *.jpg bar.js? I guess it throw a ParseError and abort lint progress?

@fisker Currently (in 1.19.1 and in this PR), the "parser can't be inferred" error is not fatal. The error is logged, the file is skipped, Prettier CLI proceeds with next file. Why would we want to hide the error? ESLint doesn't have relevant behavior because it always uses the same parser, but I don't think it ever aborts the whole linting run because of a single file.

@thorn0 I was thinking if eslint abort linting when error occurs, we can also ask people pass glob with valid extensions like prettier *.{js,css} instead of prettier *. For ESLint I never use --ext, I use **/*.{js,mjs}

Update: If eslint ignore error, we can also ignore it , so we don't need find "supported files"

@fisker Not sure how what you wrote this time is different from what you wrote before about 'I was going to do something like glob all files from dir and yield {file, ignoreNoParserError: true}'.

I'm okay with current implementation.

This is only a idea of new possible/simple solution.

I'm actually trying to rewrite it. Let's see how it goes. If it works, I'll open a new PR.

Should we merge this and release v2.0?

/cc @prettier/core Any review will be helpful.

/cc @thorn0 Can we merge it and start to release next version?

@evilebottnawi Okay, I'll do this today (if nobody objects).