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

TypeScript: functions imported from node: built-ins resolve to same-named project functions

オープン
#2,491 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

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

調査の方向性

Start by tracing how TypeScript imports are bound and how call edges resolve names; the issue does not identify specific source files or tests. Reproduce the minimal case with the node:path and node:fs imports, then check that imported external functions no longer link to same-named project functions while project imports still resolve.

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

説明

What happens

In TypeScript, a bare call to a function that is imported by name from a Node built-in module links to an unrelated project function with the same name. The import binding is ignored.

Minimal repository (CodeGraph 1.6.1, codegraph init):

// src/policy.ts
export function resolve(input: string): string { return `policy:${input}`; }
export function relative(a: string, b: string): string { return `${a}->${b}`; }
// src/io.ts
export function existsSync(path: string): boolean { return path.length > 0; }
// src/paths.ts
import { resolve, relative } from 'node:path';
import { existsSync } from 'node:fs';

export function toAbsolute(root: string, file: string): string { return resolve(root, file); }
export function toRelative(root: string, file: string): string { return relative(root, file); }
export function present(file: string): boolean { return existsSync(file); }

calls edges in the index:

toAbsolute (src/paths.ts) -> resolve (src/policy.ts)
toRelative (src/paths.ts) -> relative (src/policy.ts)
present (src/paths.ts) -> existsSync (src/io.ts)

src/paths.ts does not import src/policy.ts or src/io.ts. All three callees are node:path / node:fs functions.

Impact

On a real TypeScript repository (about 1,100 files) the same shape appears for resolve, relative, existsSync, readFileSync and unlinkSync. The project functions with those names collect many unrelated callers, so callers, impact and call-path answers for them are wrong. A tool that uses direct calls edges as proof of a call accepts these false edges.

Expected

When the callee identifier is bound by an import from a module that is not part of the project (a node: built-in, a bare built-in such as 'path' or 'fs', or an external package), the call does not resolve to a project symbol by name. It stays unresolved, or it links to an external placeholder. Calls whose binding resolves to a project file still resolve normally.

Related but different: #1987 (built-in methods on untyped receivers) and #1566 (Map.get/set/has). This case is a bare function call with an explicit import binding.

主要言語
C
スター
73.2k
フォーク
4.7k
平均マージ
2時間 16分
マージ済み PR(30日)
423

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

colbymchenry/codegraph のほかの issue

colbymchenry/codegraph の issue をすべて見る

似ている issue

C の issue をもっと見る

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

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