Closed zepfietje closed 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>
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.
The default is block
. Will look into the other item.
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...)
Thanks!
Maybe using Pint to format the PHP code isn't such a crazy idea after all? 😅
I'm still running into this issue in some places with the Filament codebase:
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
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.
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()
:Array values:
Match arms: