avoiding semi-qualified class references?

[mindplay-dk]

I have something like this:

<?php

namespace Foo\Signup;

use Foo\User;

class InvitedByEmail
{
    public function send(User $user, string $password): void
    {
        throw new User\CreateUser\UserCreateException(); // 👈🫤
    }
}

But I want something like this:

<?php

namespace Foo\Signup;

use Foo\User;
use Foo\User\CreateUser\UserCreateException; // 👈😄

class InvitedByEmail
{
    public function send(User $user, string $password): void
    {
        throw new UserCreateException(); // 👈😄
    }
}

That is, I want everything imported - I don't want these weird imports that are neither fully or unqualified.

I can't seem to configure my way around this?

I've tried every rule with the word import in it, I can't find anything that works.

It seems to happen only with certain classes, and in this specific case, Foo\User is both a namespace and a class, so admittedly, this is a bit odd - but perfectly legal in the PHP sense. I wonder if I've run into a bug/limitation of the fully_qualified_strict_types rule?

Here's my whole configuration:

<?php

$dirs = ['./lib', './public', './test', './scripts'];

$finder = (new PhpCsFixer\Finder())
    ->in($dirs);

return (new PhpCsFixer\Config())
    ->setRules([
        // coding standards:
        '@PSR12' => true,          // https://www.php-fig.org/psr/psr-12/
        '@PHP80Migration' => true, // improve PHP 8.0 compatibility

        // imports:
        'no_unused_imports' => true,
        'no_unneeded_import_alias' => true,
        "fully_qualified_strict_types" => [
            "import_symbols" => true, // simplify same-namespace imports
        ],
        "global_namespace_import" => [
            "import_classes" => true, // always import global classes
        ],
        "ordered_imports" => [
            'imports_order' => ['class', 'function', 'const'], // PSR-12 standard order
            'sort_algorithm' => 'alpha',                       // sort imports alphabetically
        ],

        // types:
        "native_type_declaration_casing" => true, // `int`, `bool` etc. (never `Int`, `Bool`, etc.)
        "ordered_types" => [
            "sort_algorithm" => "none",         // don't change the order of types
            "null_adjustment" => "always_last", // use `int|string|null` consistently, never `null|string|int` or `string|null|int` etc.
        ],
        "phpdoc_types_order" => [
            "sort_algorithm" => "none",         // see above
            "null_adjustment" => "always_last", // see above
        ],

        // syntax:
        "simple_to_complex_string_variable" => true, // convert "${var}" to "{$var}" (older syntax deprecated in PHP 8.2)
        "array_syntax" => [
            "syntax" => "short", // always ["short"] array syntax
        ],

        // formatting:
        'no_singleline_whitespace_before_semicolons' => true,
        'no_spaces_around_offset' => true,
        "array_indentation" => true,                 // regular array indentation
        'not_operator_with_successor_space' => true, // `if (! $stuff)` reads more clearly than `if (!$stuff)`

        // source control:
        "single_blank_line_at_eof" => true,    // files with no closing tag must end with line feed (better for git)
        "trailing_comma_in_multiline" => true, // trailing commas in arrays only

        // docs:
        "phpdoc_var_annotation_correct_order" => true, // PHP-DOC type and name in the correct order
        "multiline_comment_opening_closing" => true,   // doc-blocks vs multiline comments properly formatted
    ])
    ->setFinder($finder);

[Wirone]

Actually fully_qualified_strict_types has ability to shorten FQCN used in the code to minimal required QN (e.g. \Foo\User\CreateUser\UserCreateException to User\CreateUser\UserCreateException if Foo\User is imported), but it does not have an option to enforce re-import symbol using concatenated currently imported part with remaining "prefix" part. Seems like a good idea to have it 🙂.

[mindplay-dk]

I just don't want to see backslashes in names, except in the import statements in the header.

The point of listing your imports first, is you have one place where you can see all your dependencies - in my example, you still have to read through the actual code to discover the use of the exception class. It should have been referenced in the import declarations header - that's what it's for.

on the upside, I guess I can fix these manually, and it won't try to "unfix" them.

[Wirone]

No need to explain the import section's purpose to me, though 😅. I totally get it and I also prefer having only short names in the code. Just provided the information about the current state of the fully_qualified_strict_types fixer.