Source map в production: что скрывает hidden-source-map
Hidden-source-map убирает ссылку на карту из bundle, но не устанавливает контроль доступа к созданному файлу. Для production отдельно определите, какие артефакты доступны посетителям, а какие передаются только в диагностику ошибок. Отсутствие комментария не доказывает, что карта не попала на веб-сервер или промежуточное хранилище.
Какую задачу решает карта исходников
Карта связывает результат преобразования с исходным представлением и помогает разбирать ошибки. Для команды это может быть полезной частью релиза. Поэтому вопрос не обязательно сводится к полному запрету генерации: сначала определите, кому и для чего нужен соответствующий артефакт.
В описании devtool webpack hidden-source-map создаёт карту без reference comment в bundle. Документация отдельно рекомендует не доставлять такую карту на веб-сервер, если она предназначена только для обработки отчётов об ошибках. Настройка генерации и маршрут доставки — разные решения.
Три независимых вопроса к сборке
- Создаётся ли файл карты и какие сведения в него включены?
- Есть ли в выдаваемом bundle ссылка, помогающая инструментам найти карту?
- Куда фактически попал артефакт и кто может его получить?
Один параметр не отвечает сразу на все вопросы. Сборщик может корректно не вставить ссылку, а процедура публикации затем скопировать всю папку целиком. Или карта вообще не нужна браузеру, но требуется внутренней диагностике по конкретной версии релиза.
Учебная карта доставки артефактов
Предположим, релиз А включает клиентский JavaScript, карту и служебное описание состава. Обозначения условные; никакая сборка здесь не запускалась. Таблица задаёт требования к маршрутам, а не сообщает состояние реального сервера.
| Учебный артефакт | Что в нём может быть | Кому нужен | Согласованная доставка | Что проверить у готовой публикации |
|---|---|---|---|---|
| Клиентский bundle | Исполняемый клиентский код | Посетителю сайта | Публичная выдача | Нет включённых по ошибке секретных значений |
| Отдельная карта с исходным содержимым | Сопоставления и включённые исходники | Уполномоченной диагностике | По выбранной закрытой процедуре | Она не скопирована в публичный набор |
| Карта без sourcesContent | Сопоставления и другие сведения без включённого текста | По отдельному решению проекта | По согласованной модели доступа | Отсутствие исходного текста не принято за отсутствие любых сведений |
| Описание состава релиза | Связь версии с артефактами | Команде публикации и диагностики | Согласно назначению конкретного файла | Не раскрываются ненужные служебные данные |
Hidden и nosources не одно и то же
Webpack описывает nosources как отсутствие sourcesContent в карте. Hidden относится к ссылке из bundle. Не используйте эти слова как синоним полного отсутствия карты или универсальной секретности: состав и маршрут всё равно проверяют отдельно.
У других сборщиков имена настроек отличаются. Например, документация Vite по build.sourcemap описывает hidden как создание отдельной карты без соответствующих комментариев в bundle. Это не означает, что строку настройки webpack можно без изменения перенести в Vite.
Не делайте вывод о файле только по названию режима. Сохраните применимую версию, настройки и фактический состав результата. Дополнительные инструменты сборки или публикации могут менять конечный набор, который отличается от ожидаемого после чтения одного параметра.
Что значит проверить фактическую доставку
Сравните согласованный перечень публичных артефактов с тем, что процедура публикации действительно переносит. Для собственной тестовой среды проверьте доступность по разрешённому перечню, не перебирая чужие адреса. Затем подтвердите судьбу той же версии в системе диагностики, если она используется.
Если карта должна оставаться закрытой, недостаточно проверить только исходную папку сборки. Есть промежуточное хранилище, слой доставки и ранее опубликованные версии. В требованиях нужно определить, какие из них входят в область проверки и кто подтверждает результат.
Не закрывайте задачу одной отметкой «в bundle нет sourceMappingURL». Это отвечает лишь на вопрос о ссылке. Для закрытой доставки требуется другое подтверждение: выбранный артефакт не выдан обычному посетителю в проверяемой цепочке.
Как сохранить диагностику после ограничения публикации
Для внутреннего разбора ошибок нужен правильный набор той же версии. Если карта относится к другому выпуску, исчезновение публичного файла не делает диагностику корректной. Связь релиза и артефактов должна быть понятной и проверяемой.
Согласуйте, кто имеет доступ к картам и как они передаются в выбранный инструмент. Не приписывайте конкретному сервису поддержки функции, которые не проверены по его документации. В этой схеме важно требование к доставке, а не название продукта на экране.
Публичная карта и настоящие секреты
Доступность карты сама по себе не устанавливает критичность проблемы. Оцените реальные сведения, назначение клиентского кода и ожидаемые границы публикации. Но и отсутствие карты не делает переданный браузеру JavaScript тайным серверным кодом.
Если в клиентском результате оказался секрет, исправление должно учитывать сам факт его выдачи. Удаление карты не убирает значение, уже включённое в bundle. Не объявляйте вопрос решённым только после смены devtool, не проверив состав публикуемых данных.
Приёмка политики source maps
- Зафиксируйте сборщик, применимую версию и нужную диагностику production.
- Разделите требования к содержимому карты, ссылке в bundle и месту доставки.
- Согласуйте перечень публичных и закрытых артефактов релиза.
- Проверьте фактическую публикацию в разрешённой среде по этому перечню.
- Подтвердите связь закрытой карты с нужным выпуском для диагностики.
- Отдельно проверьте, не попали ли ненужные секретные данные в сам клиентский результат.
В аудите сайта такую проверку стоит оформлять как вопрос состава и доступа к артефактам. Для доработки нужны точные требования к процедуре публикации. В задаче поддержки сервера уточните фактическую выдачу через используемые слои.
Рабочий итог — полезная диагностика сохраняется в согласованной области, а публичная выдача соответствует утверждённому перечню. Называть это абсолютной защитой исходников нельзя: предмет проверки ограничен составом конкретного релиза и его доставкой.
Вопросы и ответы
Чем hidden-source-map отличается от обычной source-map?
В описанном варианте webpack карта создаётся, но ссылка на неё не добавляется в bundle. Это не правило доступа к файлу: фактическую доставку нужно проверять отдельно.
Нужно ли отключать source maps в production полностью?
Сначала определите потребность диагностики и допустимый маршрут артефактов. Возможность создавать карту для закрытой обработки отличается от решения публиковать её всем посетителям.
Что убирает nosources-source-map?
Webpack описывает отсутствие sourcesContent, а не исчезновение всех сведений карты. Сопоставления, маршрут доставки и состав самого клиентского кода требуют отдельных проверок.