Format embedded GQL in template literal statements

[keithlayne]

Description

Fixes #16007

Checklist

• I’ve added tests to confirm my change works.
• (If changing the API or CLI) I’ve documented the changes I’ve made (in the docs/ directory).
• (If the change is user-facing) I’ve added my changes to changelog_unreleased/*/XXXX.md file following changelog_unreleased/TEMPLATE.md.
• I’ve read the contributing guidelines.

✨Try the playground for this PR✨

[keithlayne]

My description of this feature is probably bad, feel free to fix :)

[sosukesuzuki]

Can you share a real world use case?

[keithlayne]

Can you share a real world use case?

I did in #16007.

[keithlayne]

I realized that probably needs clarification (my apologies), so here is a real-life example:

// card.tsx
import type { ContentItem } from './card.generated';

/* GraphQL */ `
  fragment ContentItem on ContentItem {
    id
    name
    thumbnailUri
  }
`;

export interface ContentItemCardProps {
  contentItem: ContentItem;
  children: ReactNode;
}

export const ContentItemCard = (props: ContentItemCardProps) => ...

This kind of construct is probably not useful at all in JS, but with TS + GQL is very useful for us.

Using graphql-codegen, we get named types generated for fragments that we can use (for example) in react component props. The near-operation-file (IIRC) preset is convenient here, it generates a file alongside card.tsx.

The template literals themselves are basically dead code and can be removed from bundle output.

An alternative would be to drop a graphql file alongside card.tsx, which would be fine, but for simple things like this there's some advantage to colocation.

Please lemme know if I need to clarify any more.

[keithlayne]

Also maybe worth noting that all my other tooling (codegen, GQL LSP) supports this use case well. It's just a remaining nit that I have to format it by hand right now.

[fisker]

Suggested change

	(parent.type === "ExpressionStatement" &&
	node.type === "TemplateLiteral" &&
	hasLeadingBlockCommentWithName(parent, languageName))
	(parent.type === "ExpressionStatement" &&
	hasLeadingBlockCommentWithName(parent, languageName))

[keithlayne]

Thanks - I think I realized that check wasn't strictly necessary, but I just don't know enough about how things work here, so in my mind I was playing it safe somehow. I'll update this today.

[keithlayne]

Also, would a better description be: Format embedded GQL in template literal statements?

[keithlayne]

Anything else I need to do here?

[sosukesuzuki]

Sorry for the delay, will merge when CI goes through.