Skip to content

fix(eval): stabilize eval error fingerprints and accurate .js type diagnostic#3090

Draft
posthog[bot] wants to merge 1 commit into
mainfrom
posthog-code/stable-eval-error-fingerprints
Draft

fix(eval): stabilize eval error fingerprints and accurate .js type diagnostic#3090
posthog[bot] wants to merge 1 commit into
mainfrom
posthog-code/stable-eval-error-fingerprints

Conversation

@posthog

@posthog posthog Bot commented Jul 2, 2026

Copy link
Copy Markdown

Summary

The eval engine surfaced confusing "…" is not exported by "…" errors for .js imports and filed a fresh error-tracking issue for each occurrence of the identical error. Two tightly related changes in the same area:

  • Stable fingerprints. Errors thrown from the dynamically generated Function() body in evalCompiledJs carried anonymous/eval stack frames whose line/column offsets shift with the size of the compiled code, so error tracking fingerprinted otherwise-identical errors as separate issues. evalCompiledJs now strips those generated frames, leaving a stable stack anchored at real source locations so repeat occurrences collapse into one issue.
  • Accurate .js type diagnostic. The .js/.mjs branch of import-local-file now runs getTypeExportsFromCode and sets __typeOnlyExports__, mirroring the .ts/.tsx branch, so type-only exports surfaced through .js modules get the accurate "this is a type, use export type" diagnostic instead of the generic message.

Why

One logical eval failure was fragmenting the error-tracking inbox into multiple issues (the identical defaultProps/./external.js message spawned three distinct issues within seconds), and .js imports skipped the friendlier type-only diagnostic that the .ts branch already provided. Measured impact is small — this is primarily inbox-noise cleanup.

Notes for reviewers

  • The type-only-export path is reachable when a .js module re-exports a type from a .ts module (a literal export type inside a .js file is rejected by the transpiler before it ever runs). The getTypeExportsFromCode addition brings the .js branch to full parity with the .ts branch for that case, and is harmless otherwise — the proxy only consults __typeOnlyExports__ for names that are genuinely absent at runtime.
  • The frame-stripping regex deliberately targets only generated-function frames (<anonymous>:, eval at …, bun's bare at anonymous () and leaves legitimate anonymous library frames intact.

Tests

  • tests/features/eval-error-stable-stack.test.ts — asserts eval errors carry no generated frames and that identical errors produce identical fingerprint-relevant frames regardless of compiled-code size.
  • tests/features/type-import-check-js.test.tsx — asserts the accurate "is a type" diagnostic for a type imported through a .js module.

Created with PostHog Code from an inbox report.

….js branch

Errors thrown from the dynamically generated Function() body in evalCompiledJs
carried anonymous/eval stack frames whose line/column offsets shift with the
size of the compiled code, so error tracking fingerprinted otherwise-identical
errors as separate issues. Strip those generated frames so repeat occurrences
collapse into a single issue.

Also run getTypeExportsFromCode (and set __typeOnlyExports__) in the .js/.mjs
branch of import-local-file, mirroring the .ts/.tsx branch, so type-only exports
surfaced through .js modules get the accurate "this is a type" diagnostic.

Generated-By: PostHog Code
Task-Id: 88cbfcc3-c4a7-454c-9a97-c3f645b65a90
@github-actions

github-actions Bot commented Jul 5, 2026

Copy link
Copy Markdown

This PR has been automatically marked as stale because it has had no recent activity. It will be closed if no further activity occurs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants