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: https://github.com/prettier/prettier/issues/8506#issuecomment-659604909 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: https://github.com/prettier/prettier/issues/8048#issuecomment-1030941915

[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 https://github.com/prettier/prettier/issues/8506#issuecomment-659604909. 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.

[kevinwolfcr]

Another option could be to modify the prettier config a little bit, so instead of directly adding the config, add some subprops like rules (this is where the config will live), and ignore, which is where we would be able to put multiple ignore files, and this can be compatible with tools built on top of prettier (IDE extensions, npm packages like pretty-quick for example)

Example JSON config

{
  "rules": {
    "trailingComma": "es5",
    "tabWidth": 4,
    "semi": false,
    "singleQuote": true
  },
  "ignore": [
    ".prettierignore",
    ".eslintignore",
    ".gitignore"
  ]
}

^ same as with JS, YAML, TOML, or package.json configuration

[tomdavidson]

I like the ignore object to configure, but I think .gitignore could still be a just works default.

[kevinwolfcr]

@tomdavidson:

I like the ignore object to configure, but I think .gitignore could still be a just works default.

I agree that .gitignore can be a default, but imagine this scenario:

• I am working on an Open Source project, where I automated my release process using any existing tool
• The tool calculates the version and generates a CHANGELOG.md file with the latest changes
• The CHANGELOG.md file doesn't meet my Prettier config, hence, I have a pipeline error on my CI system
• I can't ignore my CHANGELOG.md, since I want it to be on the repo for reference

[devinrhode2]

I don't really like the trend of dumping tons of config into package.json, but I can appreciate why it exists: adding 8 different config files to the root of a repo is just not that appealing.

I've setup projects setup where the package.json is only for dependencies, this allows some git pre-commit scripts to do some nifty things; for example: If package.json changes, then yarn.lock should also have changed (vast majority of the time). This means you could stage one dependency, commit, and it'll ensure the yarn.lock file only reflects changes due to adding that one dependency. Stage next dependency, commit, same thing. So yarn.lock changes are normalized and predictable.

Overall I do love .fooconfigrc.js files. I can use TS type checking via jsdoc annotations, import other files with normal node.js require or import, etc.

So if we use cosmicconfig then a .fooconfigrc.js can also come along with that, whether people put everything into package.json is their own choice ;)

[devinrhode2]

Also, first person to re-write cosmiconfig in rust or zig gets a gold star

[kevinwolfcr]

I don't really like the trend of dumping tons of config into package.json, but I can appreciate why it exists: adding 8 different config files to the root of a repo is just not that appealing.

I've setup projects setup where the package.json is only for dependencies, this allows some git pre-commit scripts to do some nifty things, like ff package.json changes, then yarn.lock should also have changed (vast majority of the time). This means you could stage one dependency, commit, and it'll ensure the yarn.lock file only reflects changes due to adding that one dependency. Stage next dependency, commit, same thing. So yarn.lock changes are normalized and predictable.

Overall I do love .fooconfigrc.js files. I can use TS type checking via jsdoc annotations, import other files with normal node.js require or import, etc.

So if we use cosmicconfig then a .fooconfigrc.js can also come along with that, whether people put everything into package.json is their own choice ;)

@devinrhode2 yep, the good think about Prettier is that it uses Cosmiconfig, so you don't have to dump everything into the package.json, you can use any flavor of .prettierrc syntax. In my case, I prefer adding them to the package.json in order to reduce the number of config files, and if we could also specify the ignore files on that same config, that'll be a plus .

[davidbludlow]

On Apr 25, 2022, @fisker said

This won't be a problem if we search .gitignore and .prettierignore by default.

I disagree. What if you don't want to use .gitignore at all? A strategy using #!include:.gitignore (see https://github.com/prettier/prettier/issues/8506#issuecomment-659604909 ) or a strategy like https://github.com/prettier/prettier/issues/8048#issuecomment-1218469292 has more flexibility.

As a sorta compromise with what you said @fisker, what if we make it so that by default, if there is no .prettierignore in the root directory, then it uses all the .gitignore files in the project, but if there is a .prettierignore, then we don't use .gitignore files unless something like #!include:.gitignore says otherwise (or unless the mechanism in https://github.com/prettier/prettier/issues/8048#issuecomment-1218469292 says otherwise, if we implement that solution). I just think if we go with a solution like what you said that "we search .gitignore and .prettierignore" then it might be annoying that you can't ignore .gitignore .

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, assuming they can override the rules somewhere else, like in .prettierignore .

[davidbludlow]

If prettier decides to go with the #!include:.gitignore Plan ( https://github.com/prettier/prettier/issues/8506#issuecomment-659604909 ), then https://github.com/kaelzhang/node-ignore/issues/58 will likely be implemented, which will be able to help other open source projects that face a similar challenge to this.

[tstibbs]

@davidbludlow I think the point about .gitignore is that I expect many of the people who want this feature want it mainly because they want to also ignore things that are already ignored in .gitignore. Thus if support for .gitignore was implemented, it could solve the problem for many people. Sure, there'd still be use-cases that required more flexibility, but I would personally vote for getting .gitignore support if that could be implemented sooner, rather than waiting for a fully flexible solution like the one you propose.

Side note: the title of this ticket suggests simply adding support for multiple files. However .gitignore files can appear in multiple locations within a project, all of which need to be considered. Having to keep track of all these files and reference them explicitiy in any calls to prettier would be error-prone. Far better if prettier could have some built-in functionality (on by default?) that looks at all .gitignore files in the project and applies their rules in the same way that git does. I'm sure the majority of users would want this.

[JaneJeon]

Ah, so I am to understand that specifying --ignore-path $file1 --ignore-path $file2 (currently) does not work?

[fisker]

I'm going to make --ignore-path accept multiple files.

[karlo-humanmanaged]

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}\"'",

[davidbludlow]

In response to what @fisker said:

I'm going to make --ignore-path accept multiple files.

IDE prettier plugins can't see that you have an --ignore-path command line argument in your prettier npm script. Since 99% of prettier users use a prettier IDE plugin, we should have a solution that all prettier IDE plugins will automatically pick up on.

(And @fisker, even though I disagree with you, I am grateful that you are active in the community)

[fisker]

we should have a solution that all prettier IDE plugins will automatically pick up on.

We can support ignore pathes in .prettierrc. We can also support patterns in .prettierrc(consider .prettierrc it self is an ignore file).

I think this will solve all related issues.

[remcohaszing]

Both those options would be great!