Использование исходных карт для отладки Sass в Chrome
Хотя это полезно, вам все равно придется отследить ошибку в вашем CSS обратно в исходный файл вручную. И редактирование CSS в браузере с использованием инструментов разработчика не может быть сохранено, поскольку оно будет перезаписано следующей компиляцией Sass.
Итак, как мы можем сделать этот процесс проще?
Я собираюсь показать вам, как использовать исходные карты в сочетании с рабочими пространствами Chrome, чтобы вы могли отлаживать и редактировать Sass из браузера.
Требования к браузеру и Sass
Функция исходных карт привлекла большое внимание, когда она была впервые представлена, и с тех пор многое изменилось. Теперь он доступен в последних стабильных версиях Chrome, Firefox и Safari.
Вам не требуется Chrome Canary, и вам не нужно редактировать chrome://flags чтобы использовать это. Вам нужно только применить правильные настройки, чтобы включить его.
Для исходных карт требуется Sass 3.3 или выше ( Sass 3.4 был выпущен недавно).
Что такое исходная карта?
Это означает, что когда ваш CSS компилируется, вы увидите комментарий, подобный следующему, в конце вашего скомпилированного файла CSS:
Как помогают Source Maps?
При проверке я хотел бы знать, где я определил color: black участок в этом.
Чтобы получить эту информацию, я мог бы выполнить одно из следующих действий для дальнейшей проверки:
Включение исходных карт в плагинах node-sass
Все плагины node-sass имеют API для включения опции карты источника Sass.
broccoli- sourceMap: true активирует исходные карты.
Включение исходных карт с использованием драгоценного камня Sass Ruby
Если вы используете гем Sass Ruby для компиляции, вы можете включить исходные карты с помощью следующей команды терминала:
Включение исходных карт с помощью Compass
Если вы используете Compass, вы можете запустить следующую команду:
Или вы можете добавить sass_options = <:sourcemap =>true> в файл config.rb и запустить config.rb compass watch как обычно.
Включение исходных карт в Chrome
Чтобы это работало в Chrome, выполните следующие действия:
Последний шаг помогает перезагрузить CSS при его изменении. Думайте об этом как о функции перезагрузки в реальном времени только для CSS.
Примечание. Вам все равно придется компилировать SCSS отдельно, используя Grunt, Gulp, sass watch или compass watch. Как только CSS будет сгенерирован, функция автоматически перезагрузит его для вас.
Живое редактирование SCSS в браузере
Включение Chrome Workspaces позволит вам сохранить (при желании) изменения, которые вы вносите в свои настоящие файлы в веб-инспекторе Chrome. Таким образом, вам не нужно пробовать свои изменения в браузере, смотреть, что работает, а затем возвращаться к своему редактору, чтобы сохранить эти изменения.
Чтобы включить рабочие области в Chrome, выполните следующие действия.
Это добавит все ваши файлы проекта на панель «Источники» в инструментах разработчика.
Отображение с локального хоста на файл на диске
Последний шаг для редактирования SCSS в браузере требует сопоставления файлов с локального хоста с исходными файлами. Выполнение следующих действий активирует это отображение:
Это соединит файл с локального хоста с файлами на реальном диске. Теперь вы можете редактировать свой SCSS в браузере, и при сохранении Chrome запишет эти изменения в фактический файл.
Если вы следите за изменениями в Sass, SCSS будет скомпилирован, и CSS автоматически обновится на вашей странице, включая ваши изменения.
Вывод
Исходные карты позволяют избежать хлопот переключения между редактором и инструментами разработчика. Он позволяет вам редактировать исходный SCSS напрямую и мгновенно видеть, как эти изменения выглядят в браузере.
Я надеюсь, что это станет ценным, экономящим время дополнением к вашему рабочему процессу.
Создание и использование 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: быстро и понятно
Механизм Source Maps используется для отображения исходных текстов программы на сгенерированные на их основе скрипты. Несмотря на то, что тема не нова и по ней уже написан ряд статей (например эта, эта и эта) некоторые аспекты все же нуждаются в прояснении. Представляемая статья представляет собой попытку упорядочить и систематизировать все, что известно по данной теме в краткой и доступной форме.
В статье Source Maps рассматриваются применительно к клиентской разработке в среде популярных браузеров (на примере, DevTools Google Chrome), хотя область их применения не привязана к какому-либо конкретному языку или среде. Главным источникам по Source Maps является, конечно, стандарт, хотя он до сих пор не принят (статус — proposal), но, тем не менее, широко поддерживается браузерами.
Работа над Source Maps была начата в конце нулевых, первая версия была создана для плагина Firebug Closure Inspector. Вторая версия вышла в 2010 и содержала изменения в части сокращения размера map-файла. Третья версия разработана в рамках сотрудничества Google и Mozilla и предложена в 2011 (последняя редакция в 2013).
В настоящее время в среде клиентской разработки сложилась ситуация, когда исходный код почти никогда не интегрируется на веб-страницу непосредственно, но проходит перед этим различные стадии обработки: минификацию, оптимизацию, конкатенацию, более того, сам исходный код может быть написан на языках требующих транспиляции. В таком случае, для целей отладки необходим механизм позволяющий наблюдать в дебаггере именно исходный, человекочитаемый код.
Для работы Source Maps необходимы следующие файлы:
Map-файл
Вся работа Source Maps основана на map-файле, который может выглядеть, например, так:
Обычно, имя map-файла складывается из имени скрипта, к которому он относится, с добавлением расширения «.map», bundle.js — bundle.js.map. Это обычный json-файл со следующими полями:
Загрузка Source Maps
Для того, чтобы браузер загрузил map-файл может быть использован один из следующих способов:
Таким образом, загрузив map-файл браузер подтянет и исходники из поля «sources» и с помощью данных в поле «mappings» отобразит их на сгенерированный скрипт. Во вкладке Sources DevTools можно будет найти оба варианта.
Для указания пути может использоваться пседопротокол file://. Также, в может быть включено все содержимое map-файла в кодировке Base64. В терминологии Webpack подобные Source Maps названы inline source maps.
Self-contained map-файлы
Код файлов-исходников можно включить непосредственно в map-файл в поле «sourcesContent», при наличии этого поля необходимость в их отдельной загрузке отпадает. В этом случае названия файлов в «sources» не отражают их реального адреса и могут быть совершенно произвольными. Именно поэтому, вы можете видеть во вкладке Sources DevTools такие странные «протоколы»: webpack://, ng:// и т.д
Mappings
Сущность механизма отображения состоит в том, что координаты (строка/столбец) имен переменных и функций в сгенерированном файле отображаются на координаты в соотвествующем файле исходного кода. Для работы механизма отображения необходима следующая информация:
(#1) номер строки в сгенерированном файле;
(#2) номер столбца в сгенерированном файле;
(#3) индекс исходника в «sources»;
(#4) номер строки исходника;
(#5) номер столбца исходника;
Все эти данные находятся в поле «mappings», значение которого — длинная строка с особой структурой и значениями закодированными в Base64 VLQ.
Строка разделена точками с запятой (;) на разделы, соответствующие строкам в сгенерированном файле (#1).
Каждый раздел разделен запятыми (,) на сегменты, каждый из которых может содержать 1,4 или 5 значений:
Каждое значение представляет собой число в формате Base64 VLQ. VLQ (Variable-length quantity) представляет собой принцип кодирования сколь угодно большого числа с помощью произвольного числа двоичных блоков фиксированной длины.
В Source Maps используются шестибитные блоки, которые следуют в порядке от младшей части числа к старшей. Старший 6-й бит каждого блока (continuation bit) зарезервирован, если он установлен, то за текущим следует следующий блок относящийся к этому же числу, если сброшен — последовательность завершена.
Поскольку в Source Maps значение должно иметь знак, для него также зарезервирован младший 1-бит (sign bit), но только в первом блоке последовательности. Как и ожидается, установленный sign бит означает отрицательное число.
Таким образом, если число можно закодировать единственным блоком, оно не может быть по модулю больше 15 (11112), так как в первом шестибитном блоке последовательности два бита зарезервированы: continuation бит всегда будет сброшен, sign бит будет установлен в зависимости от знака числа.
Шестибитные блоки VLQ отображаются на кодировку Base64, где каждой шестибитной последовательности соответствует определенный символ ASCII.
Декодируем число mE. Инверсируем порядок, младшая часть последняя — Em. Декодируем числа из Base64: E — 000100, m — 100110. В первом отбрасываем старший continuation бит и два лидирующих нуля — 100. Во втором отбрасываем старший continuation и младший sign биты (sign бит сброшен — число положительное) — 0011. В итоге получаем 100 00112, что соответствует десятичному 67.
Можно и в обратную сторону, закодируем 41. Его двоичный код 1010012, разбиваем на два блока: старшая часть — 10, младшая часть (всегда 4-битная) — 1001. К старшей части добавляем старший continuation бит (сброшен) и три лидирующих нуля — 000010. К младшей части добавляем старший continuation бит (установлен) и младший sign бит (сброшен — число положительное) — 110010. Кодируем числа в Base64: 000010 — C, 110010 — y. Инверсируем порядок и, в итоге, получаем yC.
Для работы с VLQ весьма полезна одноименная библиотека.
Время подключать исходники. Введение в Source Maps
(от перев.) О технологии работы с компилированным кодом в браузере (SourceMap) уже была подробная статья (перевод) примерно год назад. Сейчас эта технология настойчиво отвоёвывает своё место под солнцем. Например, тогда разговоры о маппинге компиляций только велись, а сейчас с версии 1.6.1 поддержку создания map-файлов получил компилятор Coffeescript. В Jetbrains Webstorm 6.0/Phpstorm (март 2013) появилась поддержка SourceMap для работы с кодом. Typescript имеет поддержку с версии 0.8.1 (ноябрь 2012). Все понимают что время ручной работы с «ассемблером» на фронтенде проходит, всем надо знать, откуда у кода ноги растут. Речь даже не идёт о начальном применении расшивки кодов минифицированных файлов — в UglifyJS, Closure Compiler и GWT (как минимум) они поддерживаются. Речь — именно о компиляторах кода JS и CSS.
Вот и недавно (в январе 2013) появилась эта большая обучающая статья, поясняющая на примерах, как работает технология кодовых карт. Хотя первая статья тоже была подробной, но не помешает и вторую иметь в переводе, она описывает то же самое другими словами и иллюстрациями, и переходит к практике — к примерам.
Перейти порог от обычного знания к опыту всегда составляет некоторый барьер. Используя учебные файлы, чтобы увидеть результаты создания файлов кодовых карт, мы между делом получим у себя на компьютере рабочую среду для сборки собственных проектов — все компиляторы и минификаторы, о которых знали, но боялись использовать, у нас будут в сборе, и останется только писать свой код на одном из экзотических до последнего времени сахарных языков фронтенда.
Обратите внимание, что если будете использовать новую версию сборщика Grunt 0.4+, то для неё будут нужны несколько другие настройки, чем описаны в статье. Подробнее о переходе с 0.3.9 на 0.4х — в habrahabr.ru/post/170937.
Автор использовала скриншоты из Мас. Для Хрома они сильно отличаются в области настроек браузера от Windows-версии, поэтому в некоторых местах добавлены скриншоты из русской версии Хрома в Windows.
Для кроссбраузерной разработки предпочтительно иметь возможность работы в любой из основных систем. Если с Linux и MacOS вопросов не возникает, то важно проверить, насколько успешно все примеры работают под Windows. В процессе перевода примеры проверялись и дорабатывались в среде Windows XP и на современных (на апрель 2013) версиях программ. В результате, в 2 из 5 примеров сделаны доработки, выложенные в статье-переводе как замечания и дополнения. (Автору статьи отправлено сообщение о доработках.) Они помогут приблизить примеры к реальности — как в плане поддержки новых версий (особенно Grunt 0.4 и Coffeescript 1.6.1), так и уверенности в работоспособности всех функций на Windows.
Следующая особенность — архив на гитхабе автора. Из-за того, что в нём есть пути длиной больше 260 символов, он полностью не раскрывается в WinRar (но это не мешает использовать стартовые файлы для примеров, у которых короткие пути и выполнить с ними все примеры). Чтобы просмотреть и распаковать (из любопытства) весь архив, в котором лежат инсталлированные после выполнения всех примеров файлы, нужно использовать 7zip или другой архиватор, отличный от WinRar.
Комментариев, замечаний и переделок накопилось достаточно много (Здесь и далее они будут выделяться форматом «цитирования» для удобства различения.) Тем не менее, это не новая статья, а перевод, с замечаниями и учётом местных и кириллических особенностей. Потому что надо отдать дань хорошей и редкой организации большой работы по отношению к популяризации новой технологии.
Но, так как обе статьи по этой теме — переведённая год назад и рассматриваемая — устарели (много не соответствующих нынешнему моменту утверждений), в этом, так сказать, переводе затронуты все вопросы, чтобы статья стала современным практическим руководством как по меппингу, как и по состоянию инструментов и браузеров на сегодня.
Что такое карты кода (source maps)?
Кодовые карты дают независимый от языка способ показа соответствия рабочего кода и исходных кодов (sources), написанных вами при разработке. Когда вы после сборки проекта посмотрите на весь подготовленный массив кодов, станет очень сложно найти соответствие участка конечного кода и его исходных строчек. Карта кода хранит эти соответствия, поэтому, когда мы запросим, например, место ошибки, то она покажет точное место её в исходном файле! Это даёт огромную пользу разработчикам, потому что код становится читаемым и даже отлаживаемым!
В этом уроке будем компилировать очень простой кусочек кодов JS + SASS, а затем просмотрим исходные файлы в браузере с помощью кодовых карт. Скачиваем демо-файлы — и приступаем!
Браузеры
Обратите внимание, что к моменту написания статьи Chrome версии 23 поддерживает JS и SASS SourceMaps. Firefox тоже получит поддержку в ближайшем будущем, так как эта тема у него в активной стадии развития. С этими оговорками, давайте посмотрим, как пользоваться картами кодов в браузере.
(прим. перев.:) В этой статье в конце имеется пример поддержки SourceMap для SASS в Firefox+Firebug. Кроме того, новое о Firefox: Future of Firefox DevTools (17 Mar 2013) или в переводе:
«Поддержка CoffeeScript. Для её реализации мы сделали поддержку SourceMap. Nick Fitzgerald продемонстрировал версию отладчика, поддерживающего SourceMap и CoffeeScript
Работа Ника помогает поддерживать в том числе минификацию файлов CSS и JS.»
Source Maps в Хроме
Для Windows (от перев.) :
1) настройка и управление (в правом верхнем углу) (F12);
2) в окне разработчика — «Settings» в правом нижнем углу;
3) выбрать «General» и “Enable source maps” в блоке «Sources».
Установка
Скачайте демо-архив (ссылка на примеры переводчика, проверенные на момент перевода) и откройте каталог «start». Файлы и структура каталога довольно просты — немного несложного JavaScript в scripts/script.js. После открывания index.html скрипт меняет цвет фона страницы по вводу кода цвета пользователем.
Посмотрите на простые скрипты в файлах на JavaScript, TypeScript и CoffeeScript.
Используя различные компиляторы, мы создадим сборку и сгенерируем соответствующие файлы кодовых карт.
Мы будем использовать 5 различных способов генерации скомпилированного и минимизированного скрипта вместе с ассоциированной картой. Вы можете перебрать все варианты или использовать только знакомый вам компилятор.
После тестирования и доработки примеров до актуальных версий программ парк примеров пополнился двумя вариантами.
2.а GruntJS (0.4.х) с JSMin.
4.а CoffeeScript — не Redux, а оригинальный, версии 1.6.2.
В первом — подробно описана установка новой версии, сильно отличающаяся от актуальной до февраля 2013 версии 0.3.х. Во втором — запуск и тестирования маппинга, появившегося с версии 1.6.1 в Coffeescript в феврале 2013. (с сентября 2012 эту роль исполнял клон — Coffeescript Redux.)
(от перев.) Первое же знакомство с кодом и предлагаемым способом переключения вариантов вызывает смущение. Нет, автором проделана большая работа и приведены потрясающие технологии. Статья отлично оформлена. Но интерфейс пользования неожиданно хромает. Способ переключения вариантов через запись и стирание комментариев противоречит идеологии подхода автоматизированной сборки — всё должно быть максимально управляемым. Показ вариантов — тоже. Ничто не мешает переключать варианты через URL страницы. Напишем переключатель, который в зависимости от параметра option в якоре загрузит тот или иной скрипт во время загрузки страницы. Это не динамическая одностраничная загрузка, хотя недалеко до неё, но уже лучше, чем переключение в коде.
Теперь мы избавились от кучи комментариев в коде, необходимости следить за ними и переключать. Добавление якоря #option= или #option= или остутствие (или ошибка формата) якоря вызовут к исполнению нужный скрипт из вариантов, перечисленных в scr.src. В дальнейшем можно добавлять свои варианты под своими именами.
И переключатель бекграунда какой-то недружественный — требует шарпа перед кодом. Понятно желание использовать цвета в словесной форме, но мало кто привык с ними работать. Подправим:
Наверное, это выглядит с первого взгляда сложно, но уже не вызывает отторжения из-за примитивности. Иначе, получается, что мы применяем новейшие технологии сборки, а выразить в коде дружественный интерфейс не в состоянии. Уже потом мы сможем оформить свои пожелания в более совершенном коде, придумать для своих кодов не такой примитивный loadScript и читатель якорей, написать всё это в кофе-скрипте и хранить в своей библиотеке сборки. Ведь к сборкам проектов мы приходим от желания не соглашаться на компромиссы примитивности и просто отображать сложную логику абстракций.
Вариант 1: Closure Compiler
Гугловский Closure Compiler — это инструмент оптимизации JavaScript. Он анализирует код, удаляет ненужные кусочки, а оставшееся — минифицирует. Кроме того, может генерировать Source Map.
Попробуйте отладку с точками останова. Наблюдаемые выражения и переменные пока недоступны при просмотре исходников. Будем надеяться, что в будущем они появятся!
Кириллические пользователи имеют счатье заметить и другой косяк, даже два: один в браузере, другой — в компиляторе. Браузер не отображает символы UTF-8 в файле, подгруженном по маппингу:
Компилятор — и того хуже: кириллические символы считает ошибкой, поэтому их надо удалить перед компиляцией (если это возможно).
Вариант 2: Задача GruntJS для JSMin
Как работать с Grunt 0.4.x
Если у вас установлена старая версия, но вы хотите обновить её до 0.4.x, то процесс установки будет другим. Прежде всего, удалите старую версию Grunt 0.3.x (если была установлена как глобальная).
Ознакомимся подробнее с установкой задач в Grunt 0.4, так как это надолго будет одним из основных инструментов сборки.
Теперь модуль Grunt в новой версии разделён на несколько модулей — ядро и плагины, чтобы вынести все коды приложений из ядра. В установке участвуют несколько модулей.
Установим интерфейс командной строки как глобальный модуль grunt-cli.
Для запуска задач в проектах этого недостаточно — в каждом проекте нужно описать задачи в файле Gruntfile. Если раньше он назывался grunt.js, то в новой версии — Gruntfile.js или Gruntfile.coffee. Второй необходимый файл в корне проекта — это package.json со списком зависимостей, использующийся в npm (Node.js package manager).
В каждой задаче в папке проекта инсталлируется локальный модуль grunt.
Поэтому зайдём в командной строке в папку «start/» и выполним там указанную команду. Как и в 0.3.x-версии, появится папка node_modules и в ней — папка модуля grunt.
Разбрасывание основного кода по проектам сделано с целью возможности запуска разных версий сбрщика на одном компьютере. grunt-cli — всего лишь оболочка, запускающая команду в нужной папке проекта. ( gruntjs.com/getting-started )
3. Отредактируйте созданный grunt.js (для версии 0.4 — создайте Gruntfile.js в «start/») так, чтобы он содержал только задачу jsmin-sourcemap — будем поступать максимально просто:
4. Вернитесь к командной строке и запустите grunt:
Это выполнит задачу jsmin-sourcemap как задачу по умолчанию, сформулированную в файле grunt.js (или Gruntfile.js ). В случае успешного результата:
(Модифицированный файл index-ru.html достаточно вызвать с якорем: localhost/index-ru.html#option=jsmin. — прим.перев.)
В этом примере у нас тоже получился маппинг исходного файла — не зря мы продирались сквозь инсталляцию сборщика. Дальше будет легче, основной инструмент — у нас в кармане.
Как видно и здесь мы наблюдаем косячки сборки, которые затем, если использовать — придётся тексты подправлять серверными скриптами и версию за версией следить за исправлениями. Такая она — разработка с инструментами на ранних стадиях готовности, при этом, очень востребованная рынком.
С Grunt и плагином jsmin-sourcemap процесс сборки создаёт 2 файла: оптимизированный скрипт со ссылкой на маппинг-файл в конце и сам файл карты кодов. Аналогично прежнему варианту, для просмотра исходников понадобятся оба файла.
Вариант 3: UglifyJS
UglifyJS2 — другой оптимизатор-компрессор JS. Как и в 2 прежних случаях, создаются оптимизированный файл скрипта, добавляется URL кодовой карты и сам файл карты, содержащий соответствия между сжатыми и исходными операторами JavaScript. Для использования выполните в каталоге » start «:
1. Инсталлируйте модуль uglify-js (создасстся каталог nocde_module/uglify-js ):
2. В каталоге “ scripts ” выполним команду создания оптимизированной версии и карты:
(На этот раз — никакого шаманства руками, всё работает.)
3. В index.html раскомментируйте вариант «Option C».
Вариант 4: CoffeeScript Redux
Так как к моменту написания статьи оригинальная сборка Coffescript от Джереми Ашкенаса не поддерживала меппинг, был использован клон, работающий с меппингом. В версии Coffescript 1.6.1+ можно использовать оригинальный язык (что, впрочем, не уменьшает других достоинств клона).
В первых 3 вариантах требовался только 1 шаг оптимизации. Для языков типа CoffeeScript нужно 2 шага: из CoffeeScript в JavaScript, а затем — в оптимизированный JS. Рассмотрим, как создать многоуровневую кодовую карту — из CoffeeScript и из компилятора CoffeeScript Redux (потому что исходный Coffeescript не поддерживал карт до версии 1.6.1 — прим. перев.).
Шаг 1: из CoffeeScript в простой JavaScript
5. Убедитесь, что в самом конце файла script.coffee.js есть URL-адрес карты кодов:
6. Убедитесь, что файл script.coffee.js.map имеет правильную ссылку на файл:
Работа с Coffeescript
Сделаем вместо работы с клоном кофе-скрипта пример с оригинальным компилятором.
Пункты 1 и 2 — остаются без изменений.
Пункт 3 — пропускаем.
4.
(«-cm» — это сокращённые параметры «—compile» и «—map».)
5. Косяки.
C созданием выходного файла — сразу пара багов. 1) файл script.coffee.js не создаётся — вместо него — script.js, затирая вариант из первых примеров. Поэтому создаём файл в отдельном каталоге (способа создать файл с другим именем в рамках одной команды не существует, если не рассматривать потоки в ОС); 2) если каталога нет, создаётся «левый» пустой каталог «/-p/» наряду с требуемым.
Для проверки путей стоит запустить этот промежуточный результат, который будет выглядеть как 6-й пример — несжатый coffeescript, и проверит правильность путей в нём.
Если создаём карту кодов одной командой (а не двумя раздельными), то в конце компилированного файла имеется комментарий вида
Оказалось, что в Хроме читается комментарий и такого вида.
И «file»: «script.js» и прочие пути в карте кодов тоже менять не понадобилось. Там находится:
Для запуска заранее выбрали такое странное имя каталога, script.c, чтобы он хорошо лёг в ранее построенный скрипт.
Так выглядит кофескрипт в отладке Хрома.
Видно, что Хром всё так же совершенно не понимает utf-8. Установка scr.setAttribute(‘charset’, ‘utf-8’); тоже не помогает.
Шаг 2: из простого JavaScript в минифицированный JS
1. Наконец, используем UglifyJS, чтобы сжать JS и создать кодовую карту. На этот раз сборщик примет кодовую карту от CoffeeScript, чтобы мы могли добраться до исходных кодов. Выполните команду в » scripts «:
2. Убедитесь, что файл карты кодов имеет правильную ссылку вида
… и правильные ссылки на исходные коды вида
… И видим, что с путём в файле творится неладное. «sources»:[«script.coffee.coffee»] должен работать, но не заработал. Но удалось увидеть исходный файл, написав (понадобилось переоткрыть браузер)
Вариант 5: TypeScript
Шаг 1: из TypeScript в простой JavaScript
Перейдите в каталог «scripts» в режиме командной строки и выполните:
Crhbgn пожаловался на несоответствие некоторых параметров для jQuery и для одного — в нашем коде:
/script.typescript.ts(7,8): The property ‘keyCode’ does not exist on value of type ‘JQueryEventObject’
Но работу принял; файл, который фактически Javascript, обработал.
Чтобы видеть изменения исходных кодов, требуется очистка кеша браузера.
Шаг 2: из простого JavaScript в минифицированный JS
Как и для CoffeweScript, следующий шаг использует UglifyJS:
Убедитесь, что ссылки в index.html указывают на правильный файл скрипта: scripts/script.typescript.min.js и откройте его в браузере.
Ошибок, связанных с компилятором и минификатором, на этом простом коде замечено не было. Исходные коды и меппинг работают без ручных правок служебных файлов.
Карты кодов для SASS
Кроме JavaScript, Chrome в настоящее время поддерживает SASS и SCSS для карт кодов. Для меппинга SASS давайте изменим некоторые настройки в Хроме и затем скомпилируем SASS в CSS с отладочными параметрами.
1. Перед изменением каких-либо настроек обратите внимание, что при наблюдении элемента из окна инструментов разработчика будем видеть только ссылку на CSS. Это не то, что нужно.
2. Заходим в chrome://flags/.
3. Устанавливаем «Enable Developer Tools experiments» (в русской версии Хрома — «Включить экспериментальные инструменты разработчика»).
В Windows:
6. Убедитесь, что окно Developer Tools переоткрыто и страница перезагружена.
7. Теперь, когда проверяем элемент в Dev.Tools, будем видеть доступ к SASS-файлу.
Кроме простого просмотра SASS, если запущен LiveReload в фоне, то при изменении SASS-файла страница тоже будет изменяться.
Теперь — откроем проект в Firefox и посмотрим через Firebug. В нём тоже будет доступен просмотр SASS-файла.
Информация о кодовых картах
Если мы посмотрим любой *.map файл, он будет содержать сопоставление информации между исходным файлом и результирующим. Структура, как правило, содержится в формате JSON по спецификации карт версии 3. Обычно, имеется 5 свойств:
1. version: версия карты (обычно 3).
2. file: имя выходного файла.
3. sources: имя исходного файла.
4. names: символы, используемые для соответствий.
5. mappings: данные соответствий.
Дополнительные ссылки
Заключение
Надеюсь, что практика использования нескольких компиляторов показала потенциал карт кодов. Хотя функциональность сейчас ограничена, в будущем есть основания ожидать возможности полноценной отладки, в том числе, в виде доступа к переменным и выражениям.
Автор: Sayanee Basu, независимый разработчик из Сингапура. В её профиле описано знание технологий Ruby и связанных с ним сахарных метаязыков. Отсюда — интерес к сырцовым картам.
Можно согласиться с автором, что «функциональность ограничена» и сказать больше — почти в каждом примере присутствовали баги с путями к файлам. Имеем состояние сырой технологии; отдалённая аналогия — примерно так было с nodeJS порядка года назад. Но объём доработок не такой большой, вопрос не года, а месяцев, и что вселяет надежду — часть багов лежит в подконтрольных кодах, написанных на nodeJS. При большом желании там можно разобраться. Но уровень гиковости для работы с этой технологией должен быть таким же, как у тех, кто ставит альфа-версии браузеров, не для развлечения, а для дела.
(Следующие вести с полей будут видимо, через пару месяцев про Firefox с его умением работать со всем этим устаканивающимся хозяйством.)
Нужно ли с этим работать сейчас? Если есть большое желание перейти на Coffeescript, то время для него уже настало. Уже сейчас можно получать неоценимый опыт отладки проектов, когда раньше приходилось работать фактически с 2 языками, помня, что отлаживать придётся JS.
Если уже используется Grunt, то для того, чтобы перейти на Кофе и SASS — сейчас дистанция вхождения стала ещё короче. Но, судя даже по примерам, надо быть готовым с головой окунуться во весь стек технологий, ища решение при выявлении багов сборки. Хорошо видно, что баги будут активно исправляться — через поддержку надстроечных языков проходит вектор интересов нескольких крупных игроков рынка, которые просто так недоработки не оставят, потому что чувствуется дыхание догоняющих, а финиш близок.
Если вы пройдёте примеры вместе с автором, или ещё лучше, затем устанОвите коды из своих проектов, проинсталлируете необходимые модули nodeJS, это будет хорошим шагом по освоению технологий фронтенд-сборки и отладки приложений.