Extend .prettierignore with an "include" syntax

[Stephen-ONeil]

A feature I'd love to see is the extension of the familliar .gitignore quasi-standard used for .prettierignore with an include syntax. E.g., #!include:.gitignore as available in .gcloudignore files.

Since .gitignore flavoured ignore files aren't really a standard, I think it's up to individual tools to provide this additional functionality.

A similar idea has been suggested (and warmly welcomed, it looks like) in #7073, with the addition of something like

"ignore": [
    { "include": "./.gitignore" },
  ]

to the Prettier config file syntax.

This would be a good short term way to get one of the popular features of #7073 out in the wild, and I don't think it would necessarily be bad to ultimately give users multiple ways to make ignore file includes anyway.

[octogonz]

@Stephen-ONeil I just noticed your issue after opening #8506 which proposes a different approach.

@thorn0 The actual work to implement either of these proposals is likely to be very small. It is an "opt-in" feature that doesn't need to wait for a major release. Thus it would be super awesome if we can resolve this without endless months of status:needs discussion.

Let's just pick a reasonable design, make a PR, and git 'er done. 😊👍👍

[alexander-akait]

👎 On this, non standard

[blaggacao]

This is a convincing syntax: #8506 (comment)
See also: kaelzhang/node-ignore#58

[jrnail23]

@evilebottnawi raises a good point about non-standard syntax. What if --ignore-path could accept an array of *ignore files, or if it would support multiples: prettier --ignore-path .gitignore --ignore-path .prettierignore?
That way you could combine the contents of the provided files.
The latter might be best for reverse-compatibility purposes.

[Stephen-ONeil]

I've got no problem with that solution, @jrnail23. I'd be happy with most of the solutions put forward in this (or any of the other related) issue threads :)

To dig deep on this though, .gitignore isn't a standard. It's a well documented and familiar syntax from a specific, widely adopted, tool. Maybe we can even pretend the git implementation is a reference implementation too. There's no spec though and, importantly, it isn't considered a standard by the git maintainers themselves. That's why I kept calling it a quasi-standard in my original post.

Not being intended as a cross-tool standard, importing from other ignore files is never going to be in scope for them. The only ignore files for them to acknowledge are .gitignore files, and they already support a number of ways to have multiple .gitignore files applying within any given context (from parent directories, the core.excludesFile config, etc). Explicit importing solves no new problems for git.

Now, I'm not saying it's not useful to pretend ignore files are a standard. Ignoring files is a common problem, and there are many reasons to want a common solution. Not least of which, I think, is that we tend to have a common set of files to ignore across our tools in the first place.

... it'd just be a lot more useful if we didn't have to manually keep that common set of ignored files in sync. The five* open issue threads in this repo alone make it clear I'm not alone.
* #8506, #8192, #8048, #7073, and this issue itself; not to mention many of these issue threads contain multiple proposed solutions

Rejecting the premise aside, I'd like to point out that # comments ARE part of the original .gitignore syntax. Technically, the line #!include:.gitignore is fully compatible with any .gitignore-style file, it's just up to the consuming tools to opt-in to the additional meaning of #!include:. If I'm right about git having no reason to implement importing, then #!include: is probably backwards compatible AND future-proof.

[fisker]

Let's add multiple ignore file support. #8506 (comment)

[kf6kjg]

A side note for those looking to include snippets into their ignore files: https://github.com/SlideWave/gitignore-include/

While this currently doesn't do recursive includes, thus preventing it from being super helpful in this exact situation, it is helpful for other related scenarios that will result in people looking at this issue. Additionally if/when the recursion feature is added, it would be able to solve this as you could have the .prettierignore file include the .gitignore file, which itself includes snippets from GitHub's gitignore project, or any other repo for that matter.

Full disclosure: I'm the author of the project.