When is prettier-plugin-astro getting some love?

[sharp tiger]

I love Astro and I realise people are working really hard to make it better everyday. And with an infinite backlog choices have to be made.

But I'm left wondering if/when prettier-plugin-astro is going to get some love. There is a fair amount of issues open, that probably overlap with a fair amount of issues that I am experiencing locally.

I'd say that prettier formatting bugs and this issue are bugging me the most on a daily basis.

Happy to help out with any of these, but I have zero experience with compilers and ASTs 😬

[viscid sinew]

I also had no compiler and AST experience when I started on those two projects, ha

I unfortunately maintain both language-tools and prettier-plugin-astro alone, and there's pretty much no contributions at all to either of these projects

I'm currently busy with other things at Astro, and so.. I only work on them essentially between tasks

If there's any particular issues you'd like to tackle, I'd be happy to onboard you / answer your questions / give as much guidance as possible

[sharp tiger]

Thanks, it helps with being patient knowing what your context is. I might have a look at reading into the source code and opening an PR for an issue here or there but my brain is pretty toasted over the weekends haha 😅 I guess prettier-plugin-astro is the easier one to contribute to compared to the compiler, as the latter isn't pure JS?

[viscid sinew]

It depends on the issue, the prettier plugin uses a JSON output produced by the compiler

It is somewhat less likely to end up in the compiler, still though

[sharp tiger]

I see! I guess most of my issues relate to formatting of elements with significant whitespace and then putting /* prettier-ignore */ comments that in turn lead to all kinds of funky bugs.

[viscid sinew]

First one would be https://github.com/withastro/prettier-plugin-astro/issues/308 I assume

The second one is in the compiler, typically it happens because the compiler reports a position wrongly (it's not necessarily hard, but it can easily lead to rabbit hole of html parsing)

For that first issue, it's unfortunately... very hard

The gist of the problem is that to format expressions, we use a JSX parser / formatter, which of course does not care about whitespace sensitivity

There's two fix:

• Write a custom JS parser (we won't do that, ha)
• Try to extract the template parts out of the expression, format both the script part and the template part individually and somehow merge the result

I think the second solution isn't that hard? Probably that there's some wonkiness to work out around indentation and stuff, but everything should be doable

Not sure if you're familiar with Rust, but it'd look like this: https://github.com/g-plane/markup_fmt/blob/19838267abc86b33a48199c8294237ecd99214d9/markup_fmt/src/printer.rs#L226-L297

[sharp tiger]

Is it true that in React this isn't an issue because it removes certain significant whitespace on render? In that case there is a third fix where we somehow do the same if template code comes from within an expression.

So embracing jsx rules within expressions

[viscid sinew]

JSX in general does not care about whitespace, since it's code (and not markup), it cannot keep the whitespaces of the code even if it wanted to

It's unlikely we'd be willing to change Astro's behavior in this regard, we're generally closer to HTML

[sharp tiger]

I see, so consistent behaviour of HTML over formatter hacks

[viscid sinew]

Yes, exactly

[sharp tiger]

Try to extract the template parts out of the expression, format both the script part and the template part individually and somehow merge the result
If you think this could be done without work on the compiler i might find myself crazy enough to at least give it a try

[viscid sinew]

It would be 100% in the prettier plugin, for sure

[sharp tiger]

Is that compiler json documented?

[viscid sinew]

No, but it's pretty straightforward, you can play around with it on this website: https://live-astro-compiler.vercel.app/ (Select "Parse" in the top right)

[sharp tiger]

or isn't that specific to Astro, but more to what prettier expects as input

[viscid sinew]

It is specific to Astro

Prettier does not actually care about the shape of the AST you give it, only that you make a Prettier Doc out of it

[sharp tiger]

Check, so because you override the parser for astro files, astro can handle any shape as long as it throws a Doc to the rest of the plugin pipeline

That Live Astro Compiler is quite nifty to look at anyway, thanks

[viscid sinew]

The person who made it is funnily enough a contributor who also had no experience with ASTs or compiler before contributing to Astro!

[sharp tiger]

I will try to give something back to the project regarding this, let me know if someone else starts working on it in the meantime, I'll leave my handle in that Github issue as well

[viscid sinew]

I heavily doubt anyone else will, haha

[sharp tiger]

Ghehe, cool

[viscid sinew]

I think the last code contribution done by someone else than me was two years ago

Fixing that issue would also close https://github.com/withastro/prettier-plugin-astro/issues/337 and https://github.com/withastro/prettier-plugin-astro/issues/403

[sharp tiger]

any thought on dprint?

as someone is avidly commenting in all those issues

[viscid sinew]

Yeah, markup_fmt is pretty cool!

[sharp tiger]

I have no experience with it, but just to keep thinking outside of the box

[viscid sinew]

The Rust code I sent is from that project

I'm a bit cautious of people advertising their projects in my issues, but still, it works (and it's the default formatter for deno fmt too)

[sharp tiger]

I'm not sure how much time/work they are ahead of the officiel prettier plugin, but if you have reasons to keep prettier being the default recommended formatter I don't mind spending time on it

[viscid sinew]

I definitely think we'll be keeping Prettier as the official recommendation for a long time still

[sharp tiger]

I feel like prettier is gonna stick around for a bit longer. I don't really feel momentum towards dprint yet. Prettier is fast enough for me

Cool thanks, I won't take more of your time until I've actually spend a bit of time on this to get a better idea whether I'm capable of solving this

[viscid sinew]

If you end up not working on that issue, let me know and I'll try allocating some time for it in the coming days/weeks

Let me know if you have any questions, always happy to help

[sharp tiger]

Awesome, thanks 🙌

Just a random comment on that throw Astro.redirect instead of return Astro.redirect (trying to work around this). I've been using the throw pattern with custom middleware for a while, but it suffers the downside that you can't throw a redirect when being in a try/catch 😅 Return works fine in that case. So i'm not sure about the throw thing