Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hidden files ignored even if explicitly defined #395

Open
3 tasks done
Rasmus-Bertell opened this issue Mar 14, 2024 · 8 comments
Open
3 tasks done

Hidden files ignored even if explicitly defined #395

Rasmus-Bertell opened this issue Mar 14, 2024 · 8 comments

Comments

@Rasmus-Bertell
Copy link

Describe the bug

I have two identical files app/Models/Locale.php and app/Models/.Locale.php phpcs only reports the errors on the first one and phpcbf only fixes the first one.

Code sample

<?php return FALSE;

To reproduce

Steps to reproduce the behavior:

  1. Create a file called test.php with the code sample above
  2. Copy the file cp test.php .test.php
  3. Run phpcs test.php
  4. Run phpcs .test.php
  5. Run phpcbf test.php
  6. Run phpcbf .test.php
$ phpcs test.php

FILE: /home/rasmus/test.php
--------------------------------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 1 LINE
--------------------------------------------------------------------------------------------
 1 | ERROR | [ ] Missing file doc comment
 1 | ERROR | [x] TRUE, FALSE and NULL must be lowercase; expected "false" but found "FALSE"
--------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------------------

Time: 35ms; Memory: 6MB

$ phpcs .test.php
$ phpcbf test.php

PHPCBF RESULT SUMMARY
----------------------------------------------------------------------
FILE                                                  FIXED  REMAINING
----------------------------------------------------------------------
/home/rasmus/test.php                                 1      1
----------------------------------------------------------------------
A TOTAL OF 1 ERROR WERE FIXED IN 1 FILE
----------------------------------------------------------------------

Time: 38ms; Memory: 6MB

$ phpcbf .test.php

No fixable errors were found

Time: 33ms; Memory: 6MB

Expected behavior

I expect it to run the same regardless of the filename.

Versions (please complete the following information)

Operating System Archlinux 6.7.9-arch1-1
PHP version 8.3.3
PHP_CodeSniffer version 3.7.2
Standard Not configured
Install type Neovim Mason plugin which still uses the old repository

Please confirm:

  • I have searched the issue list and am not opening a duplicate issue.
  • I confirm that this bug is a bug in PHP_CodeSniffer and not in one of the external standards.
  • I have verified the issue still exists in the master branch of PHP_CodeSniffer.
@jrfnl
Copy link
Member

jrfnl commented Mar 14, 2024

@Rasmus-Bertell This is not a bug, but by design. Hidden files are not checked.

Also see: squizlabs/PHP_CodeSniffer#1928

Considering this is only the second time this has comes up in 6 years, I'm not so sure it is desirable to change this behaviour in PHPCS. Moreover, as it would constitute quite a big BC-break, the change could only be made in a major release.

I'm going to leave this ticket open for a while to see if more people show interest.

@jrfnl
Copy link
Member

jrfnl commented Mar 14, 2024

Loosely related: squizlabs/PHP_CodeSniffer#2916 (checking of files without extension, which will be included in v 4.0).

@Rasmus-Bertell
Copy link
Author

I understand that hidden files are skipped when checking folders but if I explicitly define the file to be checked I would expect the program to check the file regardless of what kind of a file it is.

@jrfnl
Copy link
Member

jrfnl commented Mar 15, 2024

@Rasmus-Bertell I would consider a PR to add that as a feature in PHPCS 4.0 - allow scanning hidden files, but only when the file is explicitly declared by name in the [.]phpcs.xml[.dist] or on the command-line. Not by default and not via an include "pattern".

I suspect the change will not be that easy to make though, so I will only accept it once the existing Filter functionality has been fully covered by tests to ensure the patch doesn't break anything.

Would you be interested to work on this ?

@Rasmus-Bertell
Copy link
Author

While I would like to help, I have too many projects going on at the moment. I'll consider it when I get some of them off my plate. In the meanwhile I have a workaround to format the files so you can close this if you want to.

@jrfnl
Copy link
Member

jrfnl commented Mar 16, 2024

Understood. I'll leave the ticket open for now. There may be others interested in the feature and/or interested on working on the feature.

If not, we can always still close it at a later point in time.

@AlexSkrypnyk
Copy link

@jrfnl
I've hit both this case and a case without extension multiple times within last 6 month. Every time I had to do an ugly workaround to copy hidden/no-extension file into "normal" file and remove it after check.

I think that, if (at least) a file is specified explicitly in the config - it should be included. The config defines the user's intention. Currently, that intention is not respected. So to me, this looks like an inconsistency that would be great to have rectified.

Thank you

@jrfnl
Copy link
Member

jrfnl commented May 28, 2024

@AlexSkrypnyk Scanning files without extension is a completely different thing and is already on the roadmap for the 4.0 release.

Scanning (and by extension auto-fixing) hidden files is what this issue is about and like I said above, while I'm not necessarily against it, providing the files are explicitly requested to be scanned (by name), I will not accept a PR for this without full test coverage of the feature which is being changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants