Allow .gitignore in hidden_files

[kkmuffme]

hidden_files shouldn't report an error for .gitignore as any settings in it apply only for the plugin and its subdirectories and its often required to exclude (!) paths people might have in their global gitignore and they're using a git based deploy strategy

[kkmuffme]

Same also for .gitkeep which is mostly useful to prevent filesystem race conditions

[dd32]

These should likely remain as flagged issues in the plugin, but developers should understand what alerts they can ignore in their development environment.

The files should NOT be deployed to plugins.svn.wordpress.org, and so should not be present when PCP is run on a non-development install of the plugin.

[kkmuffme]

The files should NOT be deployed to plugins.svn.wordpress.org, and so should not be present when PCP is run on a non-development install of the plugin.

They definitely should be deployed to plugins.svn.wordpress.org.
We've had multiple users that had a git based deployment strategy for their WP sites with their .gitignore containing e.g. *.csv, example/,... which caused the plugin to be broken since our plugin contained and required data that was gitignored by their default config. By including a .gitignore with !data/csv/*.csv this issue was prevented to happen again in the future (e.g. when additional csvs are added)

The same is true for .gitkeep - without it, git would not commit the (empty) directory.

While git based deployment strategies are uncommon for private and small businesses, it's common for anything medium-enterprise since they have to validate changes between versions for security, accountability and certification reasons. And git is just the perfect tool to monitor those diffs.

[dd32]

They definitely should be deployed to plugins.svn.wordpress.org.

100% should not be.

We've had multiple users that had a git based deployment strategy for their WP sites with their .gitignore containing e.g. *.csv, example/,... which caused the plugin to be broken since our plugin contained and required data that was gitignored by their default config.

That's a bug in their deployment strategy, not in your plugin. Every plugin should not have to have a .gitignore or .gitkeep to work around bugs in someones deployment options. If someone is using Git to deploy plugins, that's OK, and totally works, but they need to verify they're importing the plugin in full if they're doing so.

In fact, in many ways, having plugins have any configuration in their plugin that affects their deployment strategy (be it deployment, or commit into that repository) would be somewhat concerning, code being inserted from a 3rd-party into their repo should not at all affect how their deployment repo operates.

.gitkeep in that case would also not likely be relevant, as empty directories serve no real purpose in this case, and the plugin can't save content in that folder anyway (Since it would be removed with updates, and if they're using .git for deployment.. chances are it's a read-only filesystem hopefully).

[swissspidy]

100% agree with @dd32 here

[davidperezgar]

I’m totally agree for what Dion says as well. PCP is meant to be run in production version of a plugin. Hidden files are not justified.

[kkmuffme]

What about:

• .editorconfig
• .wp-env.json
  ?