Is this a bug? If so which repo?

[joel-s]

Nice work on addressing my prior but tickets, team. Question for you folks.

I've got Prettier set up according to the guide on the TSRX page. I thought that if I changed some .tsx files to .tsrx files with no changes to their code, then Prettier would not change their formatting. (Otherwise when I convert my first function to use @{ ... }, code reviewers will be distracted by formatting changes in any other components in the file.)

Here's an example where the formatting was different. Would we agree this is a bug? And, if so, should I file it in tsrx-org or prettier?

[leonidaz]

aside from the different parens handling which we chose not to do as many people didn't like those extra ones, what else is wrong here? I don't see the types on visibleItems was that removed?

for the paren handling, we could introduce a flat to format jsx with parens like prettier does for jsx typically. Unless we just wanna handle it exactly how it's done for JSX.

[joel-s]

Prettier just removed the parentheses (which removed some lines) and changed how the map() was broken into lines. I was expecting that within @{ ... } there could be some new conventions, but Prettier's existing conventions would apply to JSX/TSX code.

[leonidaz]

once you switch to .tsrx, it's considered TSRX since JSX/TSX is valid TSRX.

I think we have 2 ways to go with this: always follow what prettier does for JSX/TSX for parens or have an it as an option.

I think recognizing what's tsx vs tsrx might be error prone. But this is really just a formatting preference. Like you could use a different formatter or even a different version of Prettier and get different formatting.

[joel-s]

BTW I'm OK with resolving this as not a bug, if folks feel that JSX in .tsrx files shouldn't necessarily be formatted like JSX in other files.

[leonidaz]

it's not a bug but I think it's worth having this as an option for those who prefer it, we'd need to explore how feasible this is as it could touch a lot of code in the prettier plugin and we'd need to duplicate tests.

let's leave this open and one of our ai agents will figure this out lol.

[leonidaz]

we're going to switch everything to be inline with prettier, so that means parens will be used. stay tuned.

I'm also working on a new experiment prettier plugin, based on prettier so we don't build one from scratch like we have been and hopefully it will significantly reduce the amount of issue.

but regardless, our goal is to be on parity as much as possible with prettier (3.9.6)

we'll keep the js comments in templates though.