fix: load entity files through import when require cannot parse them - #12796

Description

The new test creates a .js file containing ESM export syntax under a directory whose
package.json is {} (CommonJS), yet asserts it can be loaded via import() as ESM. This
contradicts the suite’s earlier assumption that ESM .js requires type: "module", so the test may
be Node-version dependent and not reliably validate the intended Vitest scenario.

Code

test/unit/util/import-utils.test.ts[R194-197]

+        const jsFileContent = `
+            export default function test() {}
+            export const number = 6;
+        `

Evidence

The suite’s own ESM .js test sets type: "module" before using export syntax, but the new
fallback test uses export syntax with an empty package.json (CommonJS). importOrRequireFile also
uses nearest package.json to decide CJS vs ESM for .js, so this setup is inconsistent and risks
failing outside Vite-like transforms.

test/unit/util/import-utils.test.ts[12-48]
test/unit/util/import-utils.test.ts[185-212]
src/util/ImportUtils.ts[54-63]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The test `should fall back to import when the CommonJS loader cannot parse the file` writes ESM syntax into `file.js` while also writing `package.json` as `{}`. Elsewhere in this same test suite, ESM `.js` loading is only expected to work when `package.json` has `type: "module"`.

This makes the new test brittle: in many Node configurations, `import()` of `.js` in a CommonJS package will still treat it as CommonJS and fail to parse `export` syntax, so the test may fail or not exercise the intended behavior.

### Issue Context
You want a fixture where:
1) `require()` fails with a `SyntaxError` (simulating Vitest’s CJS loader behavior), and
2) `import()` succeeds.

In plain Node, a reliable way to satisfy (2) is to make the fixture a **valid CommonJS module** (since `import()` can load CJS), while still forcing (1) via the `_extensions['.js']` stub.

### Fix Focus Areas
- test/unit/util/import-utils.test.ts[185-223]
- test/unit/util/import-utils.test.ts[12-48]
- src/util/ImportUtils.ts[54-63]

### Suggested fix
- Change `jsFileContent` in the fallback test to valid CommonJS that still yields `default` + a named export under `import()`; for example:
 - `module.exports = function test() {}; module.exports.number = 6;`
 - (Then assert `exports.default` is a function and `exports.number === 6`.)
- Keep `package.json` as `{}` to ensure `importOrRequireFile` chooses the require-first path.
- Optionally, add a comment clarifying that the fixture is intentionally CommonJS so `import()` works in Node without Vite.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

importOrRequireFile retries import() on any caught SyntaxError from require(), which can change
behavior by swallowing a real runtime-thrown SyntaxError from the module and loading successfully
via import(). This can mask legitimate failures (e.g., modules that intentionally throw SyntaxError)
and make test/prod behavior diverge depending on the runtime’s import handling.

Code

src/util/ImportUtils.ts[R38-45]

+        } catch (error) {
+            if (!(error instanceof SyntaxError)) throw error
+
+            try {
+                return await tryToImport()
+            } catch {
+                throw error
+            }

Evidence

The new helper retries on any SyntaxError, with no attempt to distinguish loader parse failures from
user-thrown runtime SyntaxErrors, so a runtime SyntaxError can be masked if import() succeeds.

src/util/ImportUtils.ts[29-46]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`tryToRequireOrImport` currently retries `import()` for **any** `SyntaxError` thrown by `require()`. This can unintentionally treat runtime-thrown `SyntaxError`s (thrown by user code) as “parse errors” and load the module via `import()`, changing behavior and potentially hiding failures.

### Issue Context
The intent is to retry only when the CommonJS loader fails to *parse* the file (e.g., TS tokens under Vitest). You can reduce behavior changes by gating the retry on heuristics that indicate a loader/parser syntax failure (message patterns, stack markers), and otherwise rethrow the original error.

### Fix Focus Areas
- src/util/ImportUtils.ts[29-46]
- src/util/ImportUtils.ts[49-63]

### Suggested fix
- Replace the broad `error instanceof SyntaxError` check with a stricter predicate, e.g.:
 - check `error instanceof SyntaxError` **and** message matches known loader parse errors (`Invalid or unexpected token`, `Unexpected token`, `Cannot use import statement outside a module`, etc.), and/or
 - check stack includes CJS loader compilation frames.
- Add/adjust a unit test that demonstrates a module that throws `new SyntaxError("...")` at runtime is **not** retried (or, if you want to support retrying it, document that behavior explicitly).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗