Multiple files for --ignore-path

[alfechner]

I use the --ignore-path argument and point it to an exhaustive .gitignore file. It's great that I don't have to duplicate the list of ignored files.

However, there are a couple of files I'd like to exclude from prettifying but still want to commit. Is there any way to specify an additonal .prettierignore file so that I can add files without copying the entire .gitignore?

[alexander-akait]

I have some idea in the past.

• .gitignore for basic ignoring setup
• .prettierignore for ignoring files for prettier

[alfechner]

Yep, this is what I'd need. In the end it's not unlikely that the files which should be ignored from git and Prettiner are partially different. Using .gitignore for Prettier is an amazing feature, but useless (for us) if we cannot enhance the ignored files.

[blaggacao]

I think this aproach is favourable: #8506 (comment)
See also: kaelzhang/node-ignore#58

[bennycode]

Is it difficult to extend the --ignore-path so it can accept a comma-separated list of files?

[lashchanka]

+1 for this:
#8048 (comment)

[SarcevicAntonio]

I'd love for prettier to automatically set --ignore-path to .prettierignore and .gitignore.

[fisker]

I think we can accept multiple --ignore-path.

But when --ignore-path is used, maybe we should not search for .prettierignore file?

[remcohaszing]

I would really like a solution that just works once configured. When I contribute to a project that uses Prettier, I expect the normal Prettier workflow to just work out of the box. I.e. I expect to be able to check the project using prettier --check ., format everything using prettier --format ., and I expect the editor integration to just work.

If a project relies on a specific command line flag, this is no longer the case. This means the project needs to document this in their contriburing guidelines, which is more effort than duplicating .gitignore into .prettierignore and is unlikely to happen. This is why I really prefer a solution that involves configuring Prettier using .prettierignore, editorconfig, and .prettierrc files, such as my proposal in #8506 (comment). Alternatively ignorePath could also be allowed in .prettierrc.

[fisker]

This won't be a problem if we search .gitignore and .prettierignore by default. Maybe we can do this in v3.

[fisker]

Alternatively ignorePath could also be allowed in .prettierrc.

This make sense.

[tomdavidson]

Ive just --ignore-path <(cat .gitignore .prettierignore) but would like ignorePath supported in the config.

[reinzor]

Ive just --ignore-path <(cat .gitignore .prettierignore) but would like ignorePath supported in the config.

Requires bash -c 'prettier --ignore-path <(cat .gitignore .prettierignore) --write .' when used as script in the package.json file. Will only work when bash installed though.

[devinrhode2]

bash -c 'prettier --ignore-path <(cat .gitignore .prettierignore) --write .'

Just tried this with yarn v1.22.19 (inside an npm script) and did not work :/

[devinrhode2]

Anything ignored by .gitignore, which we want prettier for format, could be negated inside of .prettierignore like so:

!public/*.js

[devinrhode2]

@fisker we need something that just works, i.e. one of remcohaszing's ideas

Otherwise we'll end up using a fork.... no fun

[Stephen-ONeil]

Thirding a "just works" solution, acknowledging that I've got some bias ;). When #8288 was closed I didn't say anything because I thought it was closed in favour of #8506, which was good enough for me. Didn't notice till later it was actually closed in favour of this approach.

[remcohaszing]

Both those options would be great!

[tstibbs]

bash -c 'prettier --ignore-path <(cat .gitignore .prettierignore) --write .'

Just tried this with yarn v1.22.19 (inside an npm script) and did not work :/

It is important to wrap it with bash -c Mine works by doing

"format": "bash -c 'prettier --config src/libs/eslint-config/.prettierrc.config.js --ignore-path <(cat .gitignore .prettierignore) --write \"**/*.{js,jsx,ts,tsx,md,json,css,scss,yaml,yml}\"'",

@karlo-humanmanaged my issue with this approach is that while it works in your one case where there is a single .gitignore file at the root, it doesn't support the case where there are multiple .gitignore files at multiple levels, because git applies the patterns differently depending on the level, which prettier can't do. (I accept this might be a rare case though)

[davidbludlow]

@fisker I am not sure I am understanding the details of what you are proposing, but if I am understanding what you are saying correctly, then I think it is a good solution.

[davidbludlow]

Now I am going to talk about something that might be a slightly better plan than that. (but if you disagree, then please don't let my comment stop you from implementing the good plan that I think you were saying, @fisker )

@tstibbs has convinced me that I should change my mind a bit from what I said a month ago in #8048 (comment) . Now my favorite solution is:

By default, use both .gitignore (if present) and .prettierignore (or whatever other file was specified by --ignore-path) (if present). Pay attention to .gitignore files that are in subfolders, just like git already does. Make a new option that can be put inside .prettierrc called useGitignore and have it be true by default. Setting "useGitignore": false would make it not use any .gitignore files.

The advantage of this, as @tstibbs said, is that it would work by default how most users would want it to work, since I estimate that most users would want prettier to ignore files mentioned in .gitignore (if they use git).

Also (unless I am mistaken) this plan has at least as much power and flexibility as any of the other plans that have been spoken about so far (with the possible, slight exception of the #!include:.gitignore plan)

The only negative side of this that I can see is that it may be considered a breaking change. I, however, think that this is worth a breaking change.

[fisker]

Make a new option that can be put inside .prettierrc called useGitignore and have it be true by default.

I haven't go through details yet.
My plan is search .gitignore and .prettierignore by default. But prettier --ignore-file=.prettierignore will only check files ignored by .prettierignore, not .gitignore. So we don't need useGitignore.

it may be considered a breaking change

Only if we search .gitignore by default.

[davidbludlow]

@fisker, and does your plan also allow users to specify multiple ignore files in .prettierrc.json ?

[fisker]

But, to be fair, right now I can't think of a situation in which someone would want to want prettier to pay attention to the .gitignore

I'm sorry, but I'm not sure what do you mean

1. people may want format .gitignore file
2. people may want format files ignored by .gitignore

[fisker]

@fisker, and does your plan also allow users to specify multiple ignore files in .prettierrc.json ?

Yes.

[davidbludlow]

@fisker, I meant to say, "But, to be fair, right now I can't think of a situation in which someone would want to want prettier to format files that .gitignore says should be ignored"

I think that was a typo. Sorry.

[fisker]

Funny things, our codebase need format .gitignored files.

Ignored:

prettier/.gitignore

Line 12 in cf409fe

/test*.*

Ignored:

prettier/package.json

Line 159 in cf409fe

"lint:prettier": "prettier . \"!test*\" --check",

But not ignored in .prettierignore

https://github.com/prettier/prettier/blob/main/.gitignore https://github.com/prettier/prettier/blob/main/.prettierignore

[fisker]

We put test.foo in root and run node bin/prettier test.foo to debug, but don't commit and lint/fix.

[davidbludlow]

Interesting!

[dietergeerts]

2. people may want format files ignored by .gitignore

What exactly is the value of formatting files that will not be checked in, and thus only you will see and use? I mean, Prettier is here to stop the discussion about code style in a team. If you work on your own, or have files that only you use and need, why would it matter? I don't believe that Prettier should care about this use-case, as it's not the goal of the package like described in the docs.

As for a solution, I'm not following all of them, but what I understand is that:

• a .gitignore file is there to make sure some files aren't checked in, meaning there is no point of formatting them with Prettier.
• BUT a project usually has some auto-generated files that have to be checked in, which we may not touch due to some checks (e.g. the rush install files for example, as those are checked if they are correctly generated, and formatting it breaks this), and thus EXTRA ignores are needed here.

This is why it's needed that .gitignore is kind of the default that needs to be used, and .prettierignore for these extra files.

I didn't consider CLI arguments before, but like others stated, when configuration is done through CLI args, they will not be picked up by tooling, and that makes it that you have extra work configuring all this tooling. Now if these are arguments specific to that run, then those are OK, but something like the ignore paths should not really be only as CLI argument, but part of the configuration of prettier, meaning as actual in the configuration, like already stated before in this thread, or just work that way automatically, and then IDE plugins or other tools using Prettier will just work.

Just wanted to summarise my beliefs here, as I didn't really read these directly in one of the comments above.

[connorjs]

This is why it's needed that .gitignore is kind of the default that needs to be used, and .prettierignore for these extra files.

This represents my belief too: .gitignore as a sane (and great) default, with alternative mechanisms to replace or opt-out. I am still using --ignore-file .gitignore in my package.json which fields cumbersome.

What exactly is the value of formatting files that will not be checked in, and thus only you will see and use?

Readability mostly. For example, consider generated code. You do not check it in, but you may read it. Formatting makes it easier to read.

That being said, I use other mechanisms to format generated code, usually manual commands after generation or hooks like graphql-code-generator, so using .gitignore still works perfectly for my case.

[leaumar]

If you work on your own

The benefit of making code style an automated, consistent, non-debatable thing doesn't depend on there being teammates, it's just as relevant to solo players.

I love having prettier on my pet projects so that all code (inside and across projects) reads the same and git churn/conflicts are kept to a minimum. You adapt to the tools you use, making working on code without them almost as jarring as being forced to use something other than your normal IDE.

files that will not be checked in

Formatting is a human reader's concern at least as much as it's a source control concern.

Code is code, it all does something and it all needs to be read/edited from time to time. Consistent formatting helps the reader even if a file isn't committed.

it's not the goal of the package

The mission statement not mentioning solo projects per se could be taken as an argument against making big efforts that only benefit solo players, sure, but I don't think that's what's going on here. A team is still a bunch of individuals with local files at the same time, and being used to a fixed code style transcends source control file inclusion/exclusion or team/solo as a UX matter.

[ehaynes99]

Formatting is a human reader's concern at least as much as it's a source control concern.

Code is code, it all does something and it all needs to be read/edited from time to time. Consistent formatting helps the reader even if a file isn't committed.

The entire purpose of source control is to keep track of the files intended to be read/edited by humans. That's why we use the term "source control", because it's the "source code". Compilers take code readable by humans and optimize it to be read by machines. JS happens to be an interpreted language, so the compiled artifacts are also code, but those are NOT intended to be read/edited. Dependencies and myriad other files created by tooling to be read by tooling are all similar

Consistent formatting helps the reader even if a file isn't committed.

"Not committed" is very different from "explicitly ignored". If you need to change a file in an ignored path, it's in the wrong place.

None of these change whether it's a solo project or has multiple people.

Funny things, our codebase need format .gitignored files.
Well ok, sure, if you're generating code within the formatting tool's own root directory to test the formatter, that's quite possibly the only exception I can think of. :-)

[leaumar]

but those are NOT intended to be read/edited

I can't begin to count how often I've had to read and even edit code "not meant" for reading/editing (js bundles, swagger-generated java, ...) or otherwise outside of version control to fix/research something.

The entire purpose of source control is to keep track of the files intended to be read/edited by humans

It's also about files being needed to make a project work on some level, not just who does or doesn't need to read/edit it. You can't deny sometimes you need to check in some no-touchie files and sometimes you need to go through some gitignored code. It's a big world out there with lots of different cases, what's the point to gatekeeping what does and doesn't get to be formatted?

"Not committed" is very different from "explicitly ignored"

*explicitly ignored for committing, which doesn't make a file not a legit part of the project in a minority of ways.

People want some extra control over which files are in formatting scope, not how they're formatted. File structure and all that follows from it is a matter of all tools and other concerns driving/limiting a project. There's no room for one tool to get dogmatically picky about the context you're using it in when it perfectly could just do its job. It's a file formatter, not the Multiplayer Workflow Police, and git is only a version control tool, it doesn't control other aspects of a project like which files a dev may want to read.

The stated goal of reducing friction for teams doesn't require shoehorning git into a role of permanent authority over formatting. Using and encouraging conventions to reduce configuration is one thing, conflating things and refusing to work outside those conventions is another. Being a good formatter achieves low git friction (for teams and solo), and prettier won't ever do anything other than formatting. So I'd say it's a formatter first, collaboration tool second, even if the latter's an explicit goal. Formatting is as relevant to solo workers as it is to teams, and to gitignored files as much as to committed files, because formatting is first and foremost in support of people reading/writing code wherever it is, git and colleagues not needed.

--

That discussion aside for a second, I don't see what the big deal is against letting people override the conceptual "ignore files list" parameter if they've decided they need to for whatever reason (the reason really not being prettier's problem). Default to reading [.gitignore] but let people specify other combinations. It's nothing more than a list with a default value, a pattern that's ubiquitous, easy for everyone, and super flexible. This doesn't infringe on anything else prettier might strive for while making it more useful in some cases. What does anyone win by stubbornly reading .gitignore against a user's wishes?

• prettier . is shorthand for prettier --ignore .gitignore .
• prettier --ignore .gitignore --ignore .prettierignore . if some committed files must not be touched (e.g. yarn.lock)
• prettier --ignore .prettierignore . if some committed files mustn't be touched and/or people want to format some gitignored files (e.g. "run" config, like application-local.yml for spring boot, which is an acknowledged part of every teammember's workspace even though it isn't committed)

Isn't an implicit goal of every project to maximise utility without treading on other goals, and for tools to be agnostic of things that aren't their immediate business outside of sane defaults?

[ehaynes99]

That discussion aside for a second, I don't see what the big deal is against letting people override the conceptual "ignore files list" parameter if they've decided they need to for whatever reason

The big deal is that the current behavior is wrong for the overwhelming majority of cases. This issue has been open for 3 years and has been under active discussion for ~13 months. Practically every user of the library has had to run into these problems, spend the time figuring out why it happens, and then fiddle around with copy/pasted ignore files or stuffing CLI parameters into npm scripts. I imagine a significant portion of those got frustrated enough to spend time trying to solve it "once and for all" only to realize that you can't do it with a shared config and that CLI params can't be used in a project-agnostic way in editors.

A 5-minute fix that adds path.resolve('.gitignore') here would would be a vast improvement for 99.999% of users. Discussion of that one time 2 years ago when someone needed to not just read a js bundle, but actually format it (a case where I would argue you should probably copy the file somewhere else anyway) is bikeshedding. If we have to choose, put out the house fire and start a new years-long conversation about how to light the candle. The extraordinarily uncommon use-cases should be the ones using hacks to make it work, not the other way around.

There's no room for one tool to get dogmatically picky about the context you're using it in when it perfectly could just do its job. It's a file formatter, not the Multiplayer Workflow Police, and git is only a version control tool, it doesn't control other aspects of a project like which files a dev may want to read.

"Repository" and "project" are synonyms. If "a dev may want to read" it, any dev -- including "me on my other computer" -- is going to have a hard time with that when it's not there. Deviating from that is where all of the "works on my machine" issues come from, why you find projects on GitHub that you can't compile, and why so many companies have a week(s)-long process of onboarding new developers to "get their workspace set up".

Isn't an implicit goal of every project to maximise utility without treading on other goals, and for tools to be agnostic of things that aren't their immediate business outside of sane defaults?

Often, less is more. Prettier could have had thousands of formatting options. It maximized utility by saying "no" often and unapologetically. ripgrep and fd maximized utility by honoring .gitignore for searching text & files. In fact, "zero configuration" that Just Works™ is generally as maximal utility as development tools can get.

[fisker]

@fisker, and does your plan also allow users to specify multiple ignore files in .prettierrc.json ?

Yes.

Unfortunately, it seems our config loader don't allow cli flags now. Need more work.

[Standard8]

@fisker, and does your plan also allow users to specify multiple ignore files in .prettierrc.json ?

Yes.

Unfortunately, it seems our config loader don't allow cli flags now. Need more work.

I don't understand this comment. When I played around with adding a configuration option for this previously, it would automatically add the CLI flag (stopping it adding a CLI flag didn't seem possible).

[tstibbs]

The logical successor to this feature is #14115 - I suspect many of the 77 voters on this issue are interested in this primarily so they can make prettier ignore everything ignored by git, in which case you might want to put a vote on #14115.