PHP-CS-Fixer / PHP-CS-Fixer

A tool to automatically fix PHP Coding Standards issues
https://cs.symfony.com
MIT License
12.67k stars 1.57k forks source link

Make `native_constant_invocation` platform independent #7074

Open mvorisek opened 1 year ago

mvorisek commented 1 year ago

Feature request

In a lot of projects we use pcntl constants, but with the default option - non-user constants prefixed with \, the PHP CS Fixer is unstable between linux and Windows, because the pcntl extension is for linux only, thus this issue cannot be fixed by installing all extensions on Windows, it is simply impossible.

Currently the best/working workaround is to include the constants in each project's config manually.

I submit this as a feature request to define all php-src constants, or at least the ones that are platform dependent, in PHP CS Fixer directly.

source: https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/v3.18.0/src/Fixer/ConstantNotation/NativeConstantInvocationFixer.php

example diff from Windows: image

github-actions[bot] commented 8 months ago

Since this issue has not had any activity within the last 90 days, I have marked it as stale.

The purpose of this action is to enforce backlog review once in a while. This is mostly for maintainers and helps with keeping repository in good condition, because stale issues and PRs can accumulate over time and make it harder for others to find relevant information. It is also possible that some changes has been made to the repo already, and issue or PR became outdated, but wasn't closed for some reason. This action helps with periodic review and closing of such stale items in automated way.

You may let maintainers handle this or verify current relevancy by yourself, to help with re-triage. Any activity will remove stale label so it won't be automatically closed at this point.

I will close it if no further activity occurs within the next 30 days.

SpacePossum commented 8 months ago

TBH you might be better of using docker/VM on the windows-dev machines if your target environment is not windows, but I'm sure you know that. I don't think we can really solve this in a reliable matter other than allowing users to configure all const-names that should be fixed/ignored, but that seems like a hefty price.

github-actions[bot] commented 4 months ago

Since this issue has not had any activity within the last 90 days, I have marked it as stale.

The purpose of this action is to enforce backlog review once in a while. This is mostly for maintainers and helps with keeping repository in good condition, because stale issues and PRs can accumulate over time and make it harder for others to find relevant information. It is also possible that some changes has been made to the repo already, and issue or PR became outdated, but wasn't closed for some reason. This action helps with periodic review and closing of such stale items in automated way.

You may let maintainers handle this or verify current relevancy by yourself, to help with re-triage. Any activity will remove stale label so it won't be automatically closed at this point.

I will close it if no further activity occurs within the next 30 days.

Wirone commented 4 months ago

I would rather add an configuration option to the fixer that would allow defining set of constants that should be considered as native. This way it would be flexible enough to cover your (and any other) case, without the maintenance overhead related to keeping that constants' list up-to-date.

github-actions[bot] commented 1 month ago

Since this issue has not had any activity within the last 90 days, I have marked it as stale.

The purpose of this action is to enforce backlog review once in a while. This is mostly for maintainers and helps with keeping repository in good condition, because stale issues and PRs can accumulate over time and make it harder for others to find relevant information. It is also possible that some changes has been made to the repo already, and issue or PR became outdated, but wasn't closed for some reason. This action helps with periodic review and closing of such stale items in automated way.

You may let maintainers handle this or verify current relevancy by yourself, to help with re-triage. Any activity will remove stale label so it won't be automatically closed at this point.

I will close it if no further activity occurs within the next 30 days.

github-actions[bot] commented 3 weeks ago

The fact this was automatically closed doesn't mean that the idea got rejected - it simply didn't get any priority for way too long to keep it open. If you're still interested in this, please let as know, we can consider re-opening it.

mvorisek commented 3 weeks ago

not stale