Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

no-ad-hoc-jsonl-parser: isLineSource doesn't traverse ConditionalExpression, missing live ad-hoc parse in conclusion_admission.c

オープン 初心者向け
  • 何か問題がありますか？
#71,028 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
75/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
eslint, github-actions, typescript
領域
tooling

調査の方向性

eslint-factory/src/rules/no-ad-hoc-jsonl-parser.ts と no-ad-hoc-jsonl-parser.test.ts のテストから始め、isLineSource() と fromLine() が条件式をどのように解決するかを追ってください。issue に記載された合成の有効ケースと無効ケースを追加し、その後、ルールのテストを実行して actions/setup/js/conclusion_admission.cjs をこのルールで確認してください。目標は、三項演算子で分割するケースが報告され、無関係なドキュメント配列は警告されないことです。

索引モデルが issue の本文から書いたものです。

説明

cookie eslint
Summary

no-ad-hoc-jsonl-parser's isLineSource() helper (eslint-factory/src/rules/no-ad-hoc-jsonl-parser.ts:76-98) only resolves a variable's "line-ness" through one hop of identifier-to-initializer resolution (Identifier → initializer()) and through a small whitelist of chained CallExpression methods (split, filter, slice, reverse, toReversed). It never unwraps a ConditionalExpression (ternary) to check whether either branch is itself a line source. Any line array built behind a ternary — a very ordinary "empty vs. split" guard — escapes detection entirely, including when it is subsequently JSON.parse'd per-element, which is exactly the ad-hoc-parsing idiom this rule exists to catch.

Live, grounded false negative

actions/setup/js/conclusion_admission.cjs:50-54:

const lines = compact.session === "" ? [] : compact.session.split("\n");
if (lines.at(-1) === "") lines.pop();
if ((!compact.session.endsWith("\n") && compact.session !== "") || lines.length !== compact.included_events) throw new AdmissionError();
try {
  const projected = compactUnifiedSession(lines.map(line => JSON.parse(line)));

This is a manual split-by-newline followed by .map(line => JSON.parse(line)) — the canonical pattern the rule is designed to flag (compare to the rule's own invalid test case const lines = text.split((r/redacted)?\n/); ... JSON.parse(line)). It is not wrapped by iterateJsonl/iterateJsonlEvents/JsonlParser from jsonl_helpers.cjs, yet the rule produces zero diagnostic here.

Root cause

Tracing lines in isLineSource():

  1. lines is an Identifier → initializer(node) returns its VariableDeclarator init, which is the ConditionalExpression compact.session === "" ? [] : compact.session.split("\n").
  2. isLineSource(conditionalExpr) hits if (node.type !== "CallExpression") return false; (line 83) immediately, since ConditionalExpression is neither Identifier nor CallExpression.
  3. Because isLineSource(lines) is false, the CallExpression visitor's lineArray check for lines.map(...) (arrayCallbacks.has("map") && isLineSource(node.callee.object)) never marks line as a line binding, so the later JSON.parse(line) inside the map callback is never reported.

The same gap applies to fromLine() (used for the Program:exit cross-call propagation pass), which also only descends through Identifier/ArrayExpression/MemberExpression(computed)/a small CallExpression method whitelist — no ConditionalExpression handling there either.

Proposed fix

In isLineSource() (and ideally the equivalent place in fromLine()), add a branch: if (node.type === "ConditionalExpression") return isLineSource(node.consequent, seen) || isLineSource(node.alternate, seen);. This directly fixes the cond ? [] : x.split("\n") idiom; an empty-array consequent is harmless since an empty array can't ever actually be the source of a flagged JSON.parse call.

Acceptance criteria
  • isLineSource() recognizes a ConditionalExpression as a line source when at least one branch resolves to a line source (via recursive isLineSource on consequent/alternate).
  • New invalid test case reproducing the live shape: const lines = cond ? [] : text.split("\n"); lines.map(line => JSON.parse(line)); must report adHoc.
  • A valid-case test confirms a ConditionalExpression where neither branch is a line source (e.g. cond ? documents : otherDocuments) is still not flagged.
  • conclusion_admission.cjs:54 is verified to now be caught after the fix (run against the real file, not just the synthetic test).
  • No existing passing test in no-ad-hoc-jsonl-parser.test.ts regresses.
Scope note

Out of scope for this issue: fixing conclusion_admission.cjs itself (app code, not rule code) — this is purely about closing the detection gap in the ESLint rule so a future regression or similar idiom elsewhere is caught.

Generated by 🤖 ESLint Refiner · claude · agent · 99.9 AIC · ⌖ 0.868 AIC · ⊞ 6K · ◷
Work 6b99120dce1d760d9b16b2c32e2b3939143961ca50ff5820849e9da583d8e97f · Claim c_2d1370e23519794ff88ba3c5ce7e17ee202e9a6904e679f8ad827e073d503dae_3

  • expires on Oct 28, 2026, 8:03 PM UTC-08:00
主要言語
Go
スター
5.4k
フォーク
596
平均マージ
3時間 37分
マージ済み PR（30日）
833

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

github/gh-aw のほかの issue

github/gh-aw の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。