evanw / evanw/node-source-map-support

supportRelativeURL bombs when Node "path" object is not present

Abierto
#197 3 comentarios 1 reacción 0 asignados Ver en GitHub
Lenguaje dominante
JavaScript
Estrellas
2.2k
Forks
223
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

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?).

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Línea de trabajo

Comienza en supportRelativeURL y mapSourcePosition, donde el issue informa de fallos cuando el Node path object o sus métodos no están disponibles. Compara este tratamiento con las comprobaciones de fs existentes y determina si la resolución prevista es un comportamiento resiliente o documentación en README; se considera terminado cuando el entorno Unreal-style indicado ya no falla o sus requisitos están claramente documentados.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
javascript
Área
devtools
Tipo de issue
Error
Dificultad
3/5
Tiempo estimado
1-2 días
Estado de actividad
Estancado
Claridad
Bastante claro
Aptitud para principiantes
35/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.