Skip to content

finding(scripts): two i18n gate tests still justify their fixtures by a scripts-type-check regex that #4902 replaced with an AST walk #6996

Description

@claude

Found while implementing #6666 (property-chain leg for check-i18n-dead-keys). Filed unassigned; out of scope for that PR, which touches a different mechanism.

The claim, and why it is false today

Two test files carry a constant interpolated into their fixture sources, each justified by a comment about a sibling gate's matching strategy:

  • scripts/__tests__/check-i18n-dead-keys.test.ts:31-39
  • scripts/__tests__/check-i18n-call-site-keys.test.ts:94-99

Both say, in substance, that scripts-type-check.test.ts greps scripts/ for import statements and that its regex cannot tell a string literal from a real import.

That was true when written. It is not true now. #4902 replaced the regex with an AST walk — workspaceImportSpecifiers() in scripts/__tests__/scripts-type-check.test.ts:98 builds a ts.createSourceFile and visits ImportDeclaration / ExportDeclaration / ImportEqualsDeclaration nodes. Its own docstring states the correction outright:

read from the AST rather than grepped from the file's text (objectui#4902). A textual from\s+'...' match cannot tell a real import edge apart from the same shape sitting inside a line comment, a block comment, or a JSDoc @example — this repo has hit that exact false positive

And scripts-type-check.test.ts:354-392 pins the new behaviour directly, including the case the stale comments describe as impossible to distinguish:

workspaceImportSpecifiers('probe.ts', "const doc = \"see '@object-ui/core' for details\";\n")

Why it is worth a card rather than a silent cleanup

The comments are not decoration — each one is the stated reason a fixture is built the awkward way it is. A reader who trusts them concludes that any specifier written plainly in a scripts/ test will be misread as an import edge, and keeps paying an interpolation tax that nothing charges any more. A reader who checks them discovers the sibling gate's docstring says the opposite, and now has to work out which of the two is current. That is the maintenance cost documentation drift actually imposes, and it is why #4902's own dispatch treated the false-positive class as worth a gate rather than a convention.

Two things to decide, not to assume

  1. Whether the interpolation constants (I18N_PKG and its twin) should be removed along with the comments, or kept with a corrected justification. There may be a second, still-live text-level reader of scripts/ that the comments conflate with scripts-type-check.test.tscheck-phantom-dependencies.mjs excludes scripts/ (its header, near line 185), but that is one gate checked, not the set.
  2. Whether anything else cites the pre-scripts-type-check.test.ts 的 workspace-import 检查按文本 grep,注释里的 import 示例会被判成真 import 并给出错误的修复指引 #4902 behaviour. The two hits above are what git grep finds for this wording; a broader sweep for prose describing that gate has not been done.

Reproduce

git grep -n "cannot tell a string literal" scripts/__tests__/
git grep -n "greps this directory for import" scripts/__tests__/
sed -n '81,121p' scripts/__tests__/scripts-type-check.test.ts

Measured on origin/main at 4357ec754.


Generated by Claude Code

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

    domain:devxobjectui devx stream: fix lands on .github/, scripts/ or release pipeline — devx lane cross-repofindingpriority:p3

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions