Suggestion: Return structured code path data without JSON serialization

[electrohyun]

What problem do you want to solve?

Hello! While investigating #518, I noticed a separate cleanup opportunity in the same code path data flow. This issue has a different cause and can be addressed independently, so I’m reporting it separately.

generateCodePath() creates a structured object containing codePathList, serializes it using JSON.stringify(), and returns the resulting string. The caller immediately parses that string back into an object using JSON.parse().

As a result, the current data flow is:

1. Create a JavaScript object.
2. Convert it to a JSON string.
3. Return the string to the caller.
4. Parse it back into a JavaScript object.

There is no boundary between the generator and its caller, such as a network request or storage operation, that requires the data to be serialized into a string. The conversion also discards the inferred type information, requiring the caller to use a type assertion on the parsed result.

According to the Git history, the initial implementation displayed the entire generated JSON string directly in an editor. The Code Path panel now consumes the structured codePathList data instead, but the existing serialization and parsing steps remain.

What do you think is the correct solution?

Return the structured Code Path data directly from generateCodePath() instead of converting it into a JSON string.

This could involve:

• Returning the object containing codePathList directly.
• Removing JSON.stringify() and JSON.parse().
• Updating the return type to represent the actual structured Code Path data.
• Removing the type assertion previously used on the parsed result.

Participation

• I am willing to submit a pull request for this change.

AI acknowledgment

• I did not use AI to generate this issue report.
• (If the above is not checked) I have reviewed the AI-generated content before submitting.

Additional comments

If you would prefer these changes to be handled together, I can consolidate this proposal into #518 and close this issue. Feedback on the preferred scope is welcome.

Disclosure: I'm a participant of open source contribution program OSSCA

[DMartens]

This seems to be a remnant of the client-server as mentioned in the other issue.
I agree with changing this but rather than returning it directly keeping the response property as the caller expects a "result-like" with either an object with a response or error property.
Further as there is only a single property we could pass it directly, so return { response: allCodePaths.map(...) }.
I think those two issues are independent and as such should not be combined into a single PR.