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

supportRelativeURL bombs when Node "path" object is not present

オープン
  • 何か問題がありますか？
#197 コメント 3 件 リアクション 1 件 担当者 0 名 GitHub で見る

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

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
javascript
領域
devtools

調査の方向性

supportRelativeURL と mapSourcePosition から調査を始めます。ここでは、Node path object またはそのメソッドが利用できない場合に失敗すると issue で報告されています。この処理を既存の fs チェックと比較し、意図された解決策が堅牢な動作なのか README のドキュメント化なのかを判断します。報告された Unreal-style 環境で失敗しなくなるか、その要件が明確に文書化されれば完了です。

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

説明

I am attempting to use source-map-support with a platform where v8 is embedded directly into an application, which is not Node or a browser (it's a plugin for the Unreal game engine). I do not know if this is a use case you support, but source-map-support does have many options that seem intended for making it work in unusual environments.

The Unreal environment does not have full fs or path objects (both are available through require, but return empty objects). It does have a dedicated function for loading a file into a string from disk. I am currently running this:

    require('source-map-support').install({overrideRetrieveSourceMap: true, retrieveSourceMap: function(source:string) {
        if (!source.startsWith("file:///")) { return null }
        let name = decodeURIComponent(source.substr(8)) + ".map"
        let result = JavascriptLibrary.ReadStringFromFile(null, name)
        if (!result) { return null }
        return { url: source, map: result }
      }
    })

This works except for the supportRelativeURL function, which calls both path.dirname and path.resolve without checking. In my testing, source-map-support fails 100% because supportRelativeURL gets called by mapSourcePosition. (mapSourcePosition actually calls supportRelativeURL twice. In my testing, the second one is the only one that is triggering, comment "Only return the original position if a matching line was found…". As a side note though the first call is interesting, since in cases where it does trigger, it seems to only be about maintaining the fileContentsCache. However if the user is using overrideRetrieveSourceMap— which I am— the fileContentsCache is unused, so this clause is useless work…).

If I replace the contents of supportRelativeURL with return url, source-map-support overall works great.

I am not completely sure how to proceed here. I could potentially add the missing path methods to the environment (although path.resolve concerns me since that involves per-OS support to do properly). It does seem too bad though that source-map-support almost allows me to configure it into no dependence on the filesystem, then falls down in this one function.

I think my expected behavior is that source-map-support should check for the presence of the methods on path it needs, and be resistant to path being null, since after all it already goes to the bother of doing this with fs. If this is not practical, it might help for people in unusual situations to document in the README that the path, path.dirname and path.resolve objects are required (how is it requiring "path" works in the browser, anyway?).

主要言語
JavaScript
スター
2.2k
フォーク
221
30日以内にマージされた PR はありません

環境構築

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

はじめの一歩

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

evanw/node-source-map-support のほかの issue

evanw/node-source-map-support の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

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

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