fix: dont replace define in json

[bluwy]

Description

Closes #4173

Don't run regex define replacements in JSON files as it only contains strings/booleans/numbers, to give slight perf improvements and prevent accidental replacements.

Additional context

Not sure if there's more non-js file extensions to add, but JSON seems to be the safest since Vite handles that natively.

---

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.

[patak-dev]

I wonder if we should go the other way around and use the isJSRequest(id) utility here. This isn't only for performance, if we want to avoid inconsistencies between dev and build, we shouldn't be doing replacements for define in non-js sources.
I think we can merge your PR now to close the issue, but let's explore this further.

[bluwy]

I've thought about it too but it feels like a bold move that could cause a breaking change if there are more extensions that compile to JS (Vite currently keeps a hardcoded list for it). And I can see some cases for this, like .svelte.md which is compiled by Svelte but is written in markdown.

Maybe the more robust way is to somehow identify the code is JS and then do the replacements. Or otherwise we can proceed with #3828 to make things more flexible.

[patak-dev]

Yes, #3828 got stuck because we thought there was a chance of removing this list altogether but there hasn't been progress in that direction and this is another valid use case for being able to answer the "isJSRequest" question. Maybe we should push for #3828 again.