JavaScript: fix non-FQ type on enum declarations and harden parseProject

[knutwannheden]

Motivation

Building certain TypeScript projects — originally reported for nashtech-garage/yas — fails with:

java.lang.IllegalArgumentException: A class can only be type attributed with a fully qualified type name
  at org.openrewrite.java.tree.J$ClassDeclaration.withType(J.java:1362)
  at org.openrewrite.java.internal.rpc.JavaReceiver.visitClassDeclaration(JavaReceiver.java:150)
  ...
  at org.openrewrite.rpc.RewriteRpc.getObject(RewriteRpc.java:553)
  at org.openrewrite.javascript.rpc.JavaScriptRewriteRpc$1.tryAdvance(JavaScriptRewriteRpc.java:182)

The trigger turned out to be as small as:

export enum ContentType {
  APPLICATION_JSON = 'application/json',
}

Two separate problems combined to make this a project-killer rather than a per-file error:

1. The actual bug. visitEnumDeclaration (and the other J.ClassDeclaration producers: visitClassDeclaration, visitClassExpression, visitInterfaceDeclaration) set the node's type via mapType(node), which calls checker.getTypeAtLocation(node). TypeScript resolves this to the type of the declared value — for a string enum, that collapses to the union of string-literal members and on the JS side becomes Type.Primitive.String. The Java side's J.ClassDeclaration.withType validates that the type is FullyQualified and throws.

2. No per-file resilience. The failure surfaced deep in RPC tree reconstruction (getObject), which runs outside the try/catch in parseProject's tryAdvance. A single bad file therefore aborts the entire stream instead of degrading to a ParseError for that file.

Summary

• Introduce JavaScriptTypeMapping.declarationType(node), used by visitClassDeclaration, visitClassExpression, visitInterfaceDeclaration, and visitEnumDeclaration. It resolves the declared type through the declaration's symbol:
  • For classes and interfaces, getDeclaredTypeOfSymbol yields a class-shaped ts.Type that feeds through the existing pipeline (members, methods, supertypes, type parameters preserved).
  • For enums — which have no class-shaped representation in TypeScript — we build a minimal Type.Class with classKind = Enum and the declaration's own FQN. This preserves the FullyQualified invariant.
• Extract a getFullyQualifiedNameFromSymbol(symbol) helper so the FQN logic works directly from a symbol.
• Wrap the per-file getObject(...) call in JavaScriptRewriteRpc.parseProject with a try/catch. On failure we produce a ParseError that points at the offending file and continue iterating.
• Add an optional sourcePath field to ParseProjectResponse.Item / ParseProjectResponseItem so the Java side can report which file failed when getObject throws.
• Add a regression test parseStringEnumDeclaration that parses a string enum over RPC and asserts the resulting J.ClassDeclaration carries a JavaType.Class with Kind.Enum and the right FQN.

Test plan

• New test JavaScriptRewriteRpcTest.parseStringEnumDeclaration passes
• Existing JavaScriptRewriteRpcTest suite passes
• TS-side npm run testhelper -- test/javascript/parser/ — 627 passed / 6 skipped
• License format check passes
• End-to-end: parsing the full nashtech-garage/yas/backoffice tree (206 source files) now completes with parseErrors=0, where previously it aborted mid-stream.