Skip to content

finding(scripts): js-comment-mask.mjs's scanSource @returns omits interpolation, so the one real property a .ts consumer cannot read is the third one it returns #9424

Description

@baozhoutao

Filed bare by the os-dev seat working objectui#9324 (session session_01FhBNJcLRZLe8M87VcUgpKr), as an out-of-scope observation from that card. No priority, no assignee, no grading — that is the PM's triage call.

Reading taken on origin/main = fb4ec65dafd522eaed64745ab1e29b1148a6291a. Every line number below was measured with git show against that ref.

What is wrong

tsconfig.scripts.json compiles scripts/** with allowJs: true and checkJs: false deliberately (objectui#3494), so a .ts consumer's types for scripts/js-comment-mask.mjs come from inference over the .mjs source, steered by JSDoc.

scanSource's docblock declares a two-property return:

  • scripts/js-comment-mask.mjs:220@returns naming comment and literal, both Uint8Array

Its actual return statement returns three:

  • scripts/js-comment-mask.mjs:436return { comment, literal, interpolation };

⇒ The declared return type is narrower than the real one. A .ts consumer writing scanSource(src).interpolation reads a property that genuinely exists and is genuinely populated, and gets a compile error for it.

interpolation is not vestigial — the flag array is built and post-processed on purpose, and the reasoning for the post-processing is spelled out in the comment block immediately above it (the delimiter-reachability fix that kept check-entry-guard.mjs's statement slicer from desyncing).

How many consumers that affects today

Counted over scripts/**/*.ts — the files tsconfig.scripts.json actually type-checks — reading each file's code only, with comments removed by the module's own stripComments, so a mention in prose is not scored as a read.

population count at fb4ec65daf
.ts files in the program reading .interpolation off a scanSource result 0
control, known direction: the same scan for .comment 1 — hits, so the matcher works on this input

Latent, not live. Nothing is broken today; the next consumer that wants interpolation spans is the one who pays. That is the same shape as objectui#9324 and the reason this is filed rather than dropped.

Why this was not fixed in the objectui#9324 PR

objectui#9324's dispatch names scanSource as the control that was already correct and instructs that it stay unchanged and keep passing — it is what proves the @param gap on the other three was the missing tag rather than allowJs failing to type anything. Editing the control in the same PR would have dissolved that proof. The PR (objectui#9423) therefore left scanSource byte-identical.

⚠️ Note also that this is a different defect class from objectui#9324: that card is about @param on parameters, this is about @returns on a return shape. The two happen to sit in the same file.

Suggested shape, not a ruling

Add interpolation to the @returns object type. Whether the three arrays should instead be given a named @typedef — there are three call sites destructuring the result today — is a larger question this card does not decide.

Filed by an agent seat working objectui#9324; the attribution for that run is session session_01FhBNJcLRZLe8M87VcUgpKr.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingdomain:devxobjectui devx stream: fix lands on .github/, scripts/ or release pipeline — devx lane cross-repopriority:p3

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions