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

Ruleset fully_qualified_strict_types is creating invalid code #17

Open
nickvergessen opened this issue Feb 1, 2024 · 7 comments
Open
Labels
bug Something isn't working

Comments

@nickvergessen
Copy link
Member

Talk integration tests have this file which imports TableNode:
https://github.com/nextcloud/spreed/blob/0d1fc13e36e40a6cd8dfa80915ea77f06b835f80/tests/integration/features/bootstrap/FeatureContext.php#L27

But the autofixing is breaking the docs by adding a leading \ because the file itself has no namespace

@@ -914,9 +914,9 @@
 	 * @param string $user
 	 * @param string $identifier
 	 * @param string $apiVersion
-	 * @param TableNode|null $formData
+	 * @param \TableNode|null $formData
 	 */
-	public function userCreatesRoom(string $user, string $identifier, string $apiVersion, TableNode $formData = null): void {
+	public function userCreatesRoom(string $user, string $identifier, string $apiVersion, ?TableNode $formData = null): void {
 		$this->userCreatesRoomWith($user, $identifier, 201, $apiVersion, $formData);
 	}
 
@nickvergessen nickvergessen added the bug Something isn't working label Feb 1, 2024
@come-nc
Copy link
Contributor

come-nc commented Feb 1, 2024

We should remove fully_qualified_strict_types rule and report the bug upstream I think

@nickvergessen
Copy link
Member Author

yeah let's do that and do a "quick" 1.2.1

@come-nc
Copy link
Contributor

come-nc commented Feb 1, 2024

For the record, there are several issues and PRs opened regarding this rule, I think PHP-CS-Fixer/PHP-CS-Fixer#7719 would fix the issue you had.

But for now let’s just remove the rule to be able to update our coding-standard. We may try it again in some time.

nickvergessen added a commit that referenced this issue Feb 1, 2024
There are currently too many issues for the rule on the project itself
#17
PHP-CS-Fixer/PHP-CS-Fixer#7719

Signed-off-by: Joas Schilling <213943+nickvergessen@users.noreply.github.com>
@nickvergessen
Copy link
Member Author

Let keep this open as reminder?

@nickvergessen nickvergessen changed the title 1.2 ruleset is creating invalid code Ruleset fully_qualified_strict_types is creating invalid code Feb 1, 2024
@Wirone
Copy link

Wirone commented Feb 2, 2024

IMHO you should keep fully_qualified_strict_types, but at the same time add no_superfluous_phpdoc_tags - there's no point in keeping these @params because all the information is already in the native signature. This method should look like:

    /**
	 * @Then /^user "([^"]*)" creates room "([^"]*)" \((v4)\)$/
	 */
	public function userCreatesRoom(string $user, string $identifier, string $apiVersion, ?TableNode $formData = null): void {
		$this->userCreatesRoomWith($user, $identifier, 201, $apiVersion, $formData);
	}

Then you don't need to wait for PHP-CS-Fixer/PHP-CS-Fixer#7719 and have less code in the repo 😉.

@come-nc
Copy link
Contributor

come-nc commented Feb 5, 2024

IMHO you should keep fully_qualified_strict_types, but at the same time add no_superfluous_phpdoc_tags - there's no point in keeping these @params because all the information is already in the native signature.

We most probably have tags in places which are not superfluous and those would get messed-up by the rule as well. Also seeing several bug reports and open pull request against the same rule has made me scared to add it for now.

@Wirone
Copy link

Wirone commented Feb 5, 2024

We most probably have tags in places which are not superfluous and those would get messed-up by the rule as well. Also seeing several bug reports and open pull request against the same rule has made me scared to add it for now.

Only actually superfluous tags are removed (where type in phpDoc is exactly the same as in native signature + there's no additional description), so maybe just try how it works in practice 🙂.

In terms of fully_qualified_strict_types: this rule was massively developed lately, I've added feature for importing symbols found during analysis, we added several new places where FQCN can be found and shortened, there were many other improvements like relative imports. It's natural there were issues reported, but you can clearly see these were resolved - almost all remaining issues are feature requests, there is only one bug related to edge case, but even this issue has 2 opened PRs (with alternative implementation). There's no need to be scared, just look at how many test cases we have for it 🙂.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants