当原始源是生活在sources中的依赖项，并且捆绑包是将发布到npm的库，因此源映射的node_modules数组中应使用哪种相对路径格式？以后将被捆绑到其他开发人员的下游仓库中吗？
如果这是常规应用程序捆绑包（而不是库），那么这将不是问题，因为源地图可以只使用指向所有源文件的绝对路径。但是，由于它是一个不知道将在其中部署路径的库，因此它必须仅在其源映射中使用相对路径。
但是到node_modules依赖关系的相对路径的问题是那些路径是不确定的。例如，如果我安装了依赖于some-library的{{1}}并且尚未安装graphql，则graphql将在{{1 }}（相对于我应用的package.json）。但是，如果我以前安装了npm install some-library库的另一个版本（例如，作为其他库的依赖项），那么graphql将会以./node_modules/graphql结尾。这种不可预测性意味着源映射中没有到graphql的静态相对路径。
例如，假设一个库的分发包相对于其graphql为./node_modules/some-library/graphql，并且该文件指向源映射node_modules。如果该捆绑包包含来自package.json的代码，那么源映射的./dist/some-library.js数组中该文件的路径应该是什么？
以下任何格式是否正确？如果不正确，哪种格式正确？
./dist/some-library.js.map（FWIW，这是当前使用的格式）../node_modules/graphql/module/error/index.js sources webpack:///./node_modules/graphql/module/error/index.js ~/graphql/module/error/index.js webpack:///~/graphql/module/error/index.js 顺便说一句，我认为由于摇摇树和其他原因，一个库将其他库的代码捆绑在一起是一种不好的做法。但这不是我的图书馆。它是Amazon AWS的amplify-js开源客户端库。我只想发送PR来帮助修复该库的损坏的源地图。
更改此库的整个构建过程比我在PR中愿意做的工作还要多，但是我已经implemented (in a previous PR)个自定义devtoolModuleFilenameTemplate函数来修复其他源映射路径。我必须修改该代码以解决其他一些问题，因此在进行更改时，我还想确保使用正确的node_modules路径。