Что такое source map
Преимущества использования source map на проектах
При добавлении CSS в проект, обычной практикой является разделение таблицы стилей на несколько модулей или частей. Затем мы импортируем эти части вместе с другими в один индексный файл, используя директиву @import, после чего они будут собраны с помощью LESS препроцессора в один файл CSS. Вот здесь начинается проблема. Браузеры анализируют собранный CSS, а не ваши рабочие файлы, что в конечном итоге делает отладку стилей более сложной. Выяснить, из каких именно файлов получился собранный CSS, практически невозможно.
Проблему с отладкой можно решить, используя source maps. Source maps позволяют ассоциировать собранный код с исходным кодом вашего проекта и значительно облегчить его отладку. Давайте разберёмся, как добавить поддержку source maps в проект с LESS препроцессором.
Не видно, из какого LESS-файла берутся стили, есть только reference на собранный core.css файл. Нужно активировать source maps. Подключим source maps — для этого добавим в Gruntfile.js поддержку Source maps:
При запуске будет создан grunt, начнёт обновляться файл core.css.map, а в core.css в самый конец файла добавится строка:/*# sourceMappingURL=/assets/css/core.css.map*. Теперь в Chrome DevTools мы сможем просматривать исходники LESS вот так (в Firebug не работает, но может есть какие-то дополнения, если поискать):
т.е. видно прямой reference на blocks.less вместо ссылки на скомпилированный core.css.
Можно, конечно, обходиться и без source map, но на большом проекте с множеством LESS-файлов удобство работы с LESS будет ощутимо.
Создание и использование Source Maps для css и js в GULP 4
Хотелось бы в двух словах рассказать, как настроить Source Maps для GULP 4, но не получится вырвать из контекста просто пару строк кода, поэтому разобью статью на 2 части. Первая будет с базовым кодом для Source Maps, а во второй части будет куча кода из рабочего проекта.
Так будет выглядеть в инспекторе код без Source Maps: 
Так будет выглядеть код с использованием Source Maps: 
Если вам это не нужно, то дальше можно не читать.
1. Базовый пример вывода Source Maps для js-файла
Где – plugin1() и plugin2() – это какие-то образные плагины, которые занимаются минификацией и конкатенацией js-файлов, например.
Дальше будет много кода из рабочего примера, будет использоваться scss, сборка, минификация, конкатенация и т.д.
2. Кастомизированный пример подключения Source Maps в js-файлах и в css-файлах
Задача для компиляции файла main.min.css с Source Maps
Задача для конкатенации файла scripts.min.js с Source Maps
Все классно, но есть одна проблема.
sourcemaps.write() – не указаны пути для файла *.map, значит карта источников будет записана внутри файла в самый конец, тем самым увеличивая вес файлов более чем в два раза. Это не круто, но зато карты источников будут работать и в Chrome, и в Firefox.
sourcemaps.write(‘.’) – в таком формате source map запишется отдельным файлом в той же папке, что и основной файл, в формате main.min.css.map и scripts.min.js.map.
Проблема с лишним содержимым в виде карты путей решаема.
Это часть кода из моей таски ‘build’:
По итогу, на продакшене будут чистые минифицированные файлы без лишнего кода и комментариев.
Source Maps 101
Russian (Pусский) translation by Ilya Nikov (you can also view the original English article)
В современном рабочем процессе код, который мы имеем в наших средах разработки, значительно отличается от production кода, после его запуска посредством компиляции, минимизации, конкатенации или различных других процессов оптимизации.
Здесь вступают в игру source maps, указывая точное сопоставление в нашем production коде на исходный авторский код. В этом вводном учебнике мы рассмотрим простой проект и пропустим его через различные компиляторы JavaScript, чтобы поиграться с source maps в браузере.
Что такое Source Maps?
Source Maps предлагают не зависимый от языка способ сопоставления production кода с исходным кодом.
Исходные карты предлагают не зависимый от языка способ сопоставления производственного кода с исходным кодом, который был создан в вашей среде разработки. Когда мы в конечном счете смотрим на базу кода, сгенерированную и подготовленную к production, становится очень сложно найти то место, где происходит сопоставление строк с нашим исходным авторским кодом. Однако во время компиляции source map хранит эту информацию, поэтому, когда мы запрашиваем строку, она вернет нам точное местоположение в исходном файле! Это дает огромное преимущество разработчику, поскольку код становится читаемым и даже отлаживается!
В этом уроке мы рассмотрим очень простой код JavaScript и SASS, запустим их через различные компиляторы, а затем просмотрим исходные файлы в браузере с помощью исходных карт. Загрузите демо-файлы, и давайте начнем!
Браузеры
Обратите внимание, что при написании этой статьи Chrome (версия 23) поддерживает карты исходников JavaScript и даже карты SASS. Firefox также должен получить поддержку в ближайшем будущем, так как в настоящее время он находится в активной стадии разработки. Итак, давайте посмотрим, как мы можем использовать карты источников в браузере!
Source maps в Chrome
Во-первых, мы должны включить поддержку в Chrome, выполнив следующие простые шаги:
Настройка
Просмотрите простые файлы сценариев в простых JavaScript, TypeScript или CoffeeScript. Используя различные компиляторы JavaScript, мы создадим готовую для production версию, а также сгенерируем соответствующие карты.
В следующих разделах мы будем использовать пять различных способов создания скомпилированного и мини-скрипта script.js вместе с соответствующей картой. Вы можете либо попробовать все возможные варианты или просто выбрать компилятор, с которым вы уже знакомы. Эти варианты включают:
Вариант A : компилятор Closure
Когда мы открываем index.html в браузере и перейдем к Source панели в средствах разработчика, то будет ссылка только на оптимизированную версию script.closure.js ; у нас нет способа вернуть соотношение к нашему оригинальному, исходному файлу. Давайте создадим файл карты, выполнив следующую команду в каталоге scripts :
Кроме того, попробуйте использовать точки останова для отладки, но имейте в виду, что наблюдаемые выражения и переменные пока недоступны с картами. Надеюсь, они появятся в будущем!
Вариант B : задача GruntJS для JSMin
Если вы уже используете Grunt.js для процессов сборки, вам понадобится плагин Grunt для карт JSMin. Он не только оптимизирует ваш код, но также создаст карту!
Следующие шаги продемонстрируют, как создать оптимизированную версию script.js с плагином Grunt JSMin:
С Grunt и плагином, jsmin-sourcemap, процесс сборки создал два файла: оптимизированный файл сценария с URL-адресом исходного источника, а также карту. Для просмотра всех их в браузере вам потребуются они оба.
Вариант C : UglifyJSё
Вариант D : CoffeeScript Redux
Шаг 1: CoffeeScript для простого JavaScript
Перейдите в каталог «start» в командной строке. В следующих шагах мы сопоставим оптимизированный файл сценария с CoffeeScript:
Шаг 2: Обычный JavaScript для минификации-JavaScript
Вариант E : TypeScript
Шаг 1: TypeScript для простого JavaScript
Перейдите в каталог «scripts» из командной строки и выполните следующую команду:
Шаг 2: Обычный JavaScript для минифицированного JavaScript
Как и в примере с CoffeeScript, следующим шагом будет использование UglifyJS.
Наконец, убедитесь, что index.htm l ссылается на правильный файл сценария, scripts/script.typescript.min.js и откройте его в браузере!
Карты для SASS
Помимо JavaScript, в настоящее время Chrome также поддерживает карты SASS или SCSS. Для сопоставления исходника SASS исправьте несколько настроек в Chrome, а затем скомпилируем SASS в CSS с параметрами отладки:
Помимо просто просмотра файла SASS, если вы используете LiveReload в фоновом режиме и вносите изменения в файл SASS, страница также будет обновляться, чтобы отразить изменения. Например, давайте откроем проект в Firefox и проверим страницу, используя расширение Firebug.
Информация на карте
Дополнительные ресурсы
Карты по-прежнему очень активно развиваются, но уже есть некоторые большие ресурсы, доступные в Интернете. Обязательно рассмотрите следующие, если вы хотите узнать больше.
Заключение
Надеюсь, что описанное выше использование нескольких компиляторов продемонстрировало потенциал карт. Хотя их функциональность в настоящее время ограничена, мы надеемся, в будущем у нас будет полная возможность отладки, включая доступ к переменным и выражениям.
Русские Блоги
[webpack] Какие, черт возьми, есть 7 режимов SourceMap в devtool?
Когда мы используем webpack для упаковки наших модулей проекта, нам часто требуется devtool для включения sourceMap, чтобы мы могли отлаживать код, но документация webpack предоставляет 7 режимов для devtool, а документация очень проста и трудна для начинающих. Эта статья подробно расскажет о различиях между этими 7 режимами и надеюсь, что она будет вам полезна.
Чем отличается концепция
Давайте посмотрим на описание этих 7 режимов в документе:
Примечание 1. Webpack не только поддерживает эти 7 типов, но и может по желанию комбинировать указанные выше ключевые слова eval, inline и hidden. Как сказано в документе, вы можете установить для параметра souremap значение cheap-module-inline-source-map.
Примечание 2: если ваши модули уже содержат SourceMaps, вам необходимо использоватьsource-map-loader Приходите и объединитесь, чтобы создать новые SourceMaps.
Чем отличается результат
Ниже мы перечислим результаты этих 7 режимов после упаковки и компиляции, чтобы увидеть их сходства и различия.
Это очень интуитивно понятно.Как написано в концепции в приведенной выше таблице, режим eval будет инкапсулировать каждый модуль в eval для выполнения и добавить комментарий в конце.
source-map
В то же время вы найдете еще один в своем выходном каталоге index.js.map файл.
Мы можем поставить это index.js.map Отформатируйте его, чтобы облегчить наше наблюдение и сравнение ниже:
Что касается подробного объяснения того, как информация о строке и столбце sourceMap отображает исходный код, это не та тема, на которой мы хотим сосредоточиться, поэтому она опускается. Заинтересованные ученики могут обратиться к научно-популярным статьям учителя Жуань Ифэна:Подробная карта исходного кода JavaScript
hidden-source-map
По сравнению с исходной картой, комментарии в конце отсутствуют, но index.js.map Не меньше
inline-source-map
Вы можете видеть, что комментарий sourceMap в конце встроен в пакет как DataURL.Поскольку вся информация sourceMap добавляется в пакет, весь файл пакета становится огромным.
eval-source-map
Аналогично eval, но исходная карта в комментарии преобразуется в DataURL.
cheap-source-map
Результаты аналогичны результатам, полученным с помощью source-map. в выходном каталоге index.js Содержание такое же.
Но карта дешевого источника сгенерировала index.js.map Контент больше, чем созданный исходной картой index.js.map Намного меньше кода, давайте сравним исходную карту, созданную выше index.js.map В результате обнаруживается, что свойство источника отсутствует.Информация о столбце, Остался только один «webpack:///js/index.js» 。
cheap-module-source-map
Содержимое sourceMap в разделе cheap-module-source-map меньше,Информация о столбце SourceMapУменьшено, видно, что sourcesContent также исчезли.
Какой из них лучше для такого количества режимов?
Рекомендуемая среда разработки:
Рекомендуемая производственная среда:
Введение в Javascript Source Maps
Вы когда-нибудь думали, как было бы здорово, если бы слитый в один файл и минифицированный яваскрипт код в production-окружении можено было удобно читать и даже отлаживать без ущерба производительности? Теперь это возможно, если использовать штуку под названием source maps.
Если коротко, то это способ связать минифицированный/объединённый файл с файлами, из которых он получился. Во время сборки для боевого окружения помимо минификации и объединения файлов также генерируется файл-маппер, который содержит информацию об исходных файлах. Когда производится обращение к конкретному месту в минифицированном файле, то производится поиск в маппере, по которому вычисляется строка и символ в исходном файле. Developer Tools (WebKit nightly builds или Google Chrome Canary) умеет парсить этот файл автоматически и прозрачно подменять файлы, как будто ведётся работа с исходными файлами. На момент написания (оригинальной статьи — прим. перев.) Firefox заблокировал развитие поддержки Source Map. Подробнее — на MozillaWiki Source Map.
Пример — правильное определение места в исходном коде
В этом примере можно ткнуть в любом месте textarea правой кнопкой и выбрать пункт «Get original location». При этом будет произведено обращение к файлу-мапперу с передачей строки и номера символа в минифицированном коде, и будет показан соответствующий кусок кода из исходного файла. В консоль будут выведены номер строки и номер символа в исходном файле и другая интересная информация.
Реальное использование
Прежде чем смотреть следующий пример, нужно активировать просмотр source maps в Chrome Canary или WebKit nightly, для этого в свойствах активировать пункт «Enable source maps» (см. скриншот)
Продолжим. Предыдущий пример был интересным, но как это можно использовать? Зайдите на dev.fontdragr.com настроенным браузером Google Chrome и вы увидите, что яваскрипты на странице не скомпилированы и можно смотреть отдельные js-файлы. Это всё благодаря использованию маппера, а на самом деле код на странице скомпилирован. Все ошибки, выводы в лог и точки останова будут маппиться на исходный код, и отлаживать код будет очень удобно. В итоге можно работать с production-сайтом как с тестовым.
Зачем вообще нужны Source Maps?
Google Web Toolkit (GWT) недавно добавил поддержку Source Maps и Ray Cromwell из GWT сделал отличный скринкаст, показывающий работу Source Map в действии.
Другой пример использует библиотеку Google Traceur, которая позволяет писать на ES6 (ECMAScript 6) и компилировать в ES3-совместимый код. Компилятор Traceur также генерирует source map. Посмотрите на пример использования особенностей ES6 (классов и traits), как если бы они поддерживались браузером нативно. Textarea в примере также позволяет писать ES6-код, который будет компилироваться на лету в ES3 и также будет создаваться файл-маппер.
Пример — можно написать код на ES6 и сразу посмотреть в отладчике
Как это работает?
Единственный пока компилятор/минификатор с поддержкой Source Map — Closure compiler (как при компиляции сгенерировать маппер — написано ниже). При минификации JavaScript будет создан и файл-маппер. Пока Closure compiler не добавляет в конец файла специальный комментарий для Google Chrome Canary dev tools о том, что доступен файл-маппер:
Такой комментарий позволяет браузеру искать нужное место в исходном файле, используя файл-маппер. Если идея использовать странные комментарии вам не нравится, то можно добавить к скомпилированному файлу специальный заголовок:
Как и комментарий, это скажет клиенту, где искать маппер для этого файла. Использование заголовка также позволяет работать с языками, которые не поддерживают однострочные комментарии.
Файл-маппер будет скачан только если включено свойство и открыта консоль. Ну и конечно нужно будет залить исходные файлы, чтобы они были доступны по указанным в маппере путям.
Как сгенерировать файл-маппер?
Как уже говорилось выше, нужен будет Closure compiler для минификаци, склейки и генерации файла-маппера для нужных JavaScript-файлов. Для этого нужно выполнить команду:
Внутреннее устройство Source Map
Чтобы лучше понять Source Map, возьмём для примера небольшой файл-маппер и подробно разберём, как устроена «адресация». Ниже приведён немного модифицированный пример из V3 spec:
BASE64 VLQ или как сделать Source Map маленьким
Потенциальные проблемы с XSSI
В спецификации говорится о возможных проблемах с внедрением XSS при использовании Source Map. Избавиться от неё можно, написав в начале своего map-файла » )]> «, чтобы сделать это js-файл невалидным и вызвать ошибку. WebKit dev tools уже умеет её забарывать:
Как видно, первые три символа обрезаются и производится проверка их на соответствие указанному в спецификации невалидному коду и в этом случае вырезается всё до следующего символа перевода строки.
@sourceURL и displayName в действии: eval и анонимные функции
Пример — пропущенный через eval код со сгенерированным именем
Вливайтесь
Есть очень длинное обсуждение по поддержке Source Map в CoffeeScript.
У UglifyJS также есть тикет про поддержку Source Map.
Вы можете помочь, если примете участие в обсуждении и выскажете мнение по поводу нужности поддержки Source Map. Чем больше будет инструментов, поддерживающих эту технологию, тем будет проще работать, так что требуйте её поддержки в вашем любимом OpenSource-проекте.
Source Map не идеален
Есть одна неприятность с использованием Source Map для нормальной отладки. Проблема заключается в том, что при попытке проверить значение аргумента или переменной, определённой в контексте исходного файла, контекст ничего не вернёт, т.к. он на самом деле не существует. Нужен какой-то обратный маппинг, чтобы проверить значение соответствующей переменной/аргумента в минифицированном коде и сопоставить его исходному коду.
Проблема решаемая, а при должном внимании к Source Map могут появиться ещё более интересные его применения.
Инструменты и ресурсы
Source Map — мощный инструмент для разработчика. Он позволяет держать production-код максимально сжатым, но при этом позволяет его отлаживать. Так же полезен для начинающих разработчиков, чтобы посмотреть код, написанный опытными разработчиками, чтобы поучиться правильному структурированию и написанию своего кода без необходимости продираться сквозь минифицированный код. Так чего же вы ждёте? Сгенерируйте Source Map для своего проекта!