Stillat / blade-parser-typescript

A Laravel Blade parser, compiler, and static analyzer written in TypeScript.
https://stillat.com
MIT License
90 stars 3 forks source link

Ignore Prettier print width in PHP code #46

Closed zepfietje closed 1 year ago

zepfietje commented 1 year ago

Would it be possible to ignore the Prettier print width in PHP code?

For the following cases in the Filament codebase there's some instances of code wrapping to new lines where I would rather see it unchanged.

Argument in config():

Screenshot 2023-05-23 at 10 11 13

Array values:

Screenshot 2023-05-23 at 10 12 29 Screenshot 2023-05-23 at 10 13 32

Match arms:

Screenshot 2023-05-23 at 10 14 58
JohnathonKoster commented 1 year ago

The print width setting cannot be ignored entirely, otherwise we will end up in a situation that causes everything to be on one line. However, I've made the internal print width logic smarter to help prevent the types of situations outlined in the examples here; this is available started in 1.3.0.

Additionally, I've added a new echo formatting option that matches your style a bit more closely. You can now add a new echoStyle option to a .blade.format.json file at the root of your project.

The valid options for the echoStyle option are block (the default) and inline. To illustrate what these options do, lets consider the following Blade template:

<div
{{
    match ($foo) {
        'foo' => 'foo',
        default => 'bar',
    }
}}
></div>

With the option inline, the formatted result becomes:

<div
    {{ match ($foo) {
        "foo" => "foo",
        default => "bar",
    } }}
></div>

With the option block, the formatted result is:

<div
    {{
        match ($foo) {
            "foo" => "foo",
            default => "bar",
        }
    }}
></div>
zepfietje commented 1 year ago

With 1.3.0 I'm now getting cases where things are put on a single line at a certain length:

Input:

<div
    {{
        $attributes->class([
            'foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo',
            'bar',
        ])
    }}
></div>

Output:

<div
    {{
        $attributes->class(['foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo', 'bar'])
    }}
></div>

Regarding the echoStyle option, I think we're fine with changing to the default block style though. But thanks for adding, might play around with it.

JohnathonKoster commented 1 year ago

The default is block. Will look into the other item.

JohnathonKoster commented 1 year ago

Discovered it to be some more fun prettier behavior. There is a known workaround to stop this:

<div
    {{
        $attributes->class([
            'foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo', //
            'bar',
        ])
    }}
></div>

The trailing comment will prevent it from consolidating it to the same line. This work around is incredibly dumb, and in 1.3.1 my transformer will automatically apply this workaround when it is safe to do so and then remove the added trailing comment.

Test coverage added for this additional edge case (getting really tempted to write my own PHP formatter...)

zepfietje commented 1 year ago

Thanks!

Maybe using Pint to format the PHP code isn't such a crazy idea after all? 😅

zepfietje commented 1 year ago

I'm still running into this issue in some places with the Filament codebase:

Screenshot 2023-05-24 at 08 45 00
JohnathonKoster commented 1 year ago

I've added support for the new feature to directives now as well in 1.3.2.

Maybe using Pint to format the PHP code isn't such a crazy idea after all?

Its something I can explore as an optional feature; but need to remain conscious of the fact that the formatter is not always running in an environment that can run other commands (browser/some sandboxed environments, etc.). Lots of thinking/exploration to do here

zepfietje commented 1 year ago

I've added support for the new feature to directives now as well in 1.3.2.

Thanks!

Its something I can explore as an optional feature; but need to remain conscious of the fact that the formatter is not always running in an environment that can run other commands (browser/some sandboxed environments, etc.). Lots of thinking/exploration to do here

Yeah totally understand. Let me know if you want to brainstorm about this.