evanw / evanw/node-source-map-support
supportRelativeURL bombs when Node "path" object is not present
- 主要言語
- JavaScript
- スター
- 2.2k
- フォーク
- 223
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
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](https://github.com/ncsoft/Unreal.js/blob/master/README.md)). 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?).
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
調査の方向性
supportRelativeURL と mapSourcePosition から調査を始めます。ここでは、Node path object またはそのメソッドが利用できない場合に失敗すると issue で報告されています。この処理を既存の fs チェックと比較し、意図された解決策が堅牢な動作なのか README のドキュメント化なのかを判断します。報告された Unreal-style 環境で失敗しなくなるか、その要件が明確に文書化されれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- javascript
- 領域
- devtools
- issue の種類
- バグ
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100