Какой формат относительного пути следует использовать в массиве sources исходной карты, когда исходный источник является зависимостью, которая находится в node_modules, и когда пакет представляет собой библиотеку, которая будет опубликована в npm и которая, следовательно, будет повторно позже в комплекте в репозитории других разработчиков?
Если бы это был обычный пакет приложений (не библиотека), то это не было бы проблемой, потому что исходная карта могла бы просто использовать абсолютный путь ко всем исходным файлам. Но поскольку это библиотека, которая не знает пути, где она будет развернута, она должна использовать только относительные пути в своей исходной карте.
Но проблема с относительными путями к зависимостям node_modules заключается в том, что эти пути недетерминированы. Например, если я установлю some-library, который зависит от graphql, а graphql еще не установлен, то npm install some-library установит graphql в ./node_modules/graphql (относительно package.json моего приложения). Но если я ранее установил другую версию библиотеки graphql (например, в качестве зависимости другой библиотеки), то graphql окажется в ./node_modules/some-library/graphql. Эта непредсказуемость означает, что в исходной карте нет статического относительного пути к node_modules.
Например, предположим, что дистрибутив библиотеки, относительно ее package.json, равен ./dist/some-library.js, и этот файл указывает на исходную карту ./dist/some-library.js.map. Если этот пакет включает код из ../node_modules/graphql/module/error/index.js, каким должен быть путь к этому файлу в массиве sources исходной карты?
Является ли какой-либо из приведенных ниже форматов правильным, а если нет, то какой правильный формат?
webpack:///./node_modules/graphql/module/error/index.js (FWIW, этот формат используется в настоящее время) ~/graphql/module/error/index.jswebpack:///~/graphql/module/error/index.jswebpack://~/graphql/module/error/index.js../node_modules/graphql/module/error/index.js./node_modules/graphql/module/error/index.js
Кстати, я предполагаю, что из-за тряски деревьев и по другим причинам плохая практика для библиотеки - объединять код других библиотек. Но это не моя библиотека. Это клиентская библиотека Amazon 10 с открытым исходным кодом ampify-js . Я просто хочу отправить PR, чтобы помочь исправить поврежденные исходные карты этой библиотеки.
Изменение всего процесса сборки этой библиотеки - это больше работы, чем я готов сделать в PR, но я уже реализовал (в предыдущем PR) пользовательский devtoolModuleFilenameTemplate функция для исправления других путей к исходной карте. Я должен пересмотреть этот код, чтобы исправить некоторые другие проблемы, поэтому, пока я делаю изменения, я также хотел убедиться, что используются правильные пути node_modules.