This change affects three rules.
Would it be better to simply ignore it? How should I handle it?
Once this is decided, I will also add tests.

Don't care about if nextChar doesn't exist because of typescript error & parsing error.

[Bug] Tagged templates can have arbitrary nodes as children. This is totally valid:

`
${new (class {
    value = `
  
  ${(() => `C:\D`)()}}
  `
  })().value
  }
`;

https://typescript-eslint.io/play#ts=5.8.2&showAST=ts&fileType=.tsx&code=AYKAJA3gdgpg7gAgBQGMA2BDAzlhEQKEIBuGaArjAgLwKiEEKRJICUNAfHQMIBcAOgBFgrNgF8xjegjGjWAOlIUYjScADcQA&eslintrc=N4KABGBEBOCuA2BTAzpAXGYBfEWg&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false

I don't think any kind of state on Converter is going to scale. Instead, I think checking node.parent might be the only way to do it?

node.parent is more safe & simple. I committed.

😬 this and #isInTaggedTemplate are a lot of logic to add. If it does stay in, I think this should at least be extracted to its own separate function to keep Converter from getting even more complex. Finding a package on npm that already does this would be even better.

But, can we get away with checking if template.text === template.rawText?

I think template.text === template.rawText is difficult to solve this issue.
As node.text(node: ts.NoSubstitutionTemplateLiteral | ts.TemplateHead | ts.TemplateMiddle | ts.TemplateTail) is handle its escape char and , this condition is difficult when valid and invalid escape chrs are mixed.

So, find package is better. I found unraw package that parse escape chr and throws err when it is invalid. (I wanted to compare different packages, but I couldn't find any other suitable ones.)

I committed.

Maybe we can eval node.rawText it directly?

try {
  new Function(`return \`${node.rawText}\`;`)();
  return true;
} catch {
  return false;
}

I see they are stored in .templateSpans

Ah, that's better. Thank you. For me, it's a much lighter and simpler way than adding dependencies, so I committed it. However, I know that eval has performance and security issues. Will this be okay? @JoshuaKGoldberg

p.s I tried to use ts.createSourceFile, but it fails in test cases.

ts.createSourceFile(
   'temp.ts',
   `const str = \`${text}\`;`,
    ts.ScriptTarget.Latest,
);

convert > tagged template literal cooked > should set cooked to null for invalid escape sequences in tagged template literals
AssertionError: expected '\n\uXXXXᄑ\t' to be null

- Expected: 
null

+ Received: 
"
\\uXXXXᄑ       "

convert > tagged template literal cooked > should set cooked to null for mixed valid and invalid escape sequences
AssertionError: expected '\uXXXX\xQW' to be null

- Expected: 
null

+ Received: 
"\\uXXXX\\xQW"

I think I should defer to @bradzacher on this. I'm quite weary of taking on eval or new Function. Even if we assume there are no security concerns, both are quite slow. I think we'd need to see benchmarks showing they don't significantly change parsing times for very large files that include many large template literals and edge cases.

Since there is no ast-spec dependency in types, need to set inputs to update the cache hash.
+I think also enhance copy-ast-spec cache.

      "copy-ast-spec": {
        "cache":true,
        "command": "tsx tools/copy-ast-spec.mts",
        "dependsOn": [
          "ast-spec:build"
        ],
        "options": {
          "cwd": "{projectRoot}"
        },
        "outputs": [
          "{projectRoot}/src/generated"
        ]
       "inputs":[
         "file of types..."
       ]
      },

By the way, should I create a separate issue for this task?

We should add some tests for template with expressions.

Ah, thanks to you I found and fixed the bug.