fix(ssr): avoid transforming json file in ssrTransform

[poyoho]

Description

fix: #6154

Additional context

• `filter json file transform in ssrTransform.
• need to filter json tree shaking in runtime phase?

In the transform phase of the plugin, dataToEsm is called for tree shaking, but I think that in the runtime phase, there should be no need to shake the json tree, and it may directly return a string. I am not sure whether this point needs to be changed.

feat json ignore named export option in ssr.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[bluwy]

In the transform phase of the plugin, dataToEsm is called for tree shaking, but I think that in the runtime phase, there should be no need to shake the json tree, and it may directly return a string. I am not sure whether this point needs to be changed.

Good point. I think in dev it's fine to not treeshake as bundle size is not a concern, plus the issues showed that Node parses it fairly faster as well. In build we can treeshake the JSON (which I believe is handled separately).

Also, the PR title ssrTransfrom -> ssrTransform 😬

[poyoho]

@bluwy I found out why I need to call datatoesm. Not only for tree sharking, but also for named exports I think we can only optimize the situation where named exports is not required. 😂

[bluwy]

I think we missed out on merging this. It looks good to me, but the PR now needs a rebase.

[poyoho]

done. the unit test meeting a common mistake.