Введение в Source Maps

в 14:18, , рубрики: data mining, Анализ и проектирование систем, иностранные языки, Новости, новостные ресурсы, переводы, метки: , , ,

В современной разработке ваш код сильно отличается от кода на «боевом» сервере (production) после компиляции, минификации, объединения и разных оптимизаций. Тут-то и вступают в игру карты кода (source maps), показывая точное соответствие элементов готового рабочего кода проекта и вашего кода разработки. В этом вводном уроке мы возьмём простой проект и запустим его с помощью различных компиляторов JavaScript с целью посмотреть работу карт кода в браузере.

(от перев.) О технологии работы с компилированным кодом в браузере (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, а затем просмотрим исходные файлы в браузере с помощью кодовых карт. Скачиваем демо-файлы — и приступаем!

Поскольку в примерах будет работать современная версия Grunt (0.4), рекомендуется скачивать не примеры автора, а обновлённые примеры переводчика. В них лежат как стартовые файлы, так и результаты инсталляций и работы примеров, чтобы можно было проверить правильность и успешность своих действий --прим.перев. .

Браузеры

Обратите внимание, что к моменту написания статьи Chrome версии 23 поддерживает JS и SASS SourceMaps. Firefox тоже получит поддержку в ближайшем будущем, так как эта тема у него в активной стадии развития. С этими оговорками, давайте посмотрим, как пользоваться картами кодов в браузере.

(прим. перев.:) В этой статье в конце имеется пример поддержки SourceMap для SASS в Firefox+Firebug. Кроме того, новое о Firefox: Future of Firefox DevTools (17 Mar 2013) или в переводе:
«Поддержка CoffeeScript. Для её реализации мы сделали поддержку SourceMap. Nick Fitzgerald продемонстрировал версию отладчика, поддерживающего SourceMap и CoffeeScript
Введение в Source Maps
Работа Ника помогает поддерживать в том числе минификацию файлов CSS и JS.»

*) wiki.mozilla.org/DevTools/Features/SourceMap

Source Maps в Хроме

Прежде всего, нам нужно включить поддержку меппинга в настройках:
1) открыть окно Chrome Developer Tools: View -> Developer -> Developer Tools (F12);
2) нажать «Settings» в правом нижнем углу;
3) выбрать «General» и “Enable source maps”.
Введение в Source Maps

Для Windows (от перев.):
1) настройка и управление (в правом верхнем углу) (F12);
2) в окне разработчика — «Settings» в правом нижнем углу;
3) выбрать «General» и “Enable source maps” в блоке «Sources».
      Введение в Source Maps

Установка

Скачайте демо-архив и откройте каталог «start». Файлы и структура каталога довольно просты — немного несложного JavaScript в scripts/script.js. После открывания index.html скрипт меняет цвет фона страницы по вводу кода цвета пользователем.

Введение в Source Maps

$ tree
├── index.html
├── scripts
│   ├── jquery.d.ts
│   ├── script.coffee.coffee
│   ├── script.js
│   └── script.typescript.ts
└── styles
    ├── style.css
    └── style.sass

Посмотрите на простые скрипты в файлах на JavaScript, TypeScript и CoffeeScript.
Используя различные компиляторы, мы создадим сборку и сгенерируем соответствующие файлы кодовых карт.

Мы будем использовать 5 различных способов генерации скомпилированного и минимизированного скрипта вместе с ассоциированной картой. Вы можете перебрать все варианты или использовать только знакомый вам компилятор.

Варианты:
1. Closure Compiler.
2. GruntJS с JSMin.
3. Uglifyjs 2.
4. CoffeeScript Redux.
5. TypeScript.

После тестирования и доработки примеров до актуальных версий программ парк примеров пополнился двумя вариантами.

2.а GruntJS (0.4.х) с JSMin.
4.а CoffeeScript — не Redux, а оригинальный, версии 1.6.2.

В первом — подробно описана установка новой версии, сильно отличающаяся от актуальной до февраля 2013 версии 0.3.х. Во втором — запуск и тестирования маппинга, появившегося с версии 1.6.1 в Coffeescript в феврале 2013. (с сентября 2012 эту роль исполнял клон — Coffeescript Redux.)

(от перев.) Первое же знакомство с кодом и предлагаемым способом переключения вариантов вызывает смущение. Нет, автором проделана большая работа и приведены потрясающие технологии. Статья отлично оформлена. Но интерфейс пользования неожиданно хромает. Способ переключения вариантов через запись и стирание комментариев противоречит идеологии подхода автоматизированной сборки — всё должно быть максимально управляемым. Показ вариантов — тоже. Ничто не мешает переключать варианты через URL страницы. Напишем переключатель, который в зависимости от параметра option в якоре загрузит тот или иной скрипт во время загрузки страницы. Это не динамическая одностраничная загрузка, хотя недалеко до неё, но уже лучше, чем переключение в коде.

var lHash = location.hash.substr(1).split('=');
if(lHash && lHash.length ==2 && lHash[0] =='option')
	var optionName = lHash[1];
if(optionName && !parseInt(optionName))
	optionName = {closure:1,jsmin:2,uglifyjs:3,coffeescript:4,typescript:5}[optionName.toLowerCase()];
console.log(optionName);
optionName = optionName ||0;
var loadScript;
(loadScript = function(i){
	var scr = document.createElement('SCRIPT');
	scr.setAttribute('type', 'application/javascript');
	scr.src ='scripts/script.'
		+ ('|closure|jsmin-grunt|uglify|coffee.min|typescript.min'.split('|')[i])
		+(i?'.':'') +'js';
	document.getElementsByTagName('head')[0].appendChild(scr);
})(optionName);

Теперь мы избавились от кучи комментариев в коде, необходимости следить за ними и переключать. Добавление якоря #option=<число> или #option=<имя_примера> или остутствие (или ошибка формата) якоря вызовут к исполнению нужный скрипт из вариантов, перечисленных в scr.src. В дальнейшем можно добавлять свои варианты под своими именами.

И переключатель бекграунда какой-то недружественный — требует шарпа перед кодом. Понятно желание использовать цвета в словесной форме, но мало кто привык с ними работать. Подправим:

var colr = $("#color").val().toUpperCase()
	, cL = colr.length;
for(var i in cL)
	if(cL[i] <'0'|| cL[i] >'9'&& cL[i] <'A'|| cL[i] >'F') //найден не hex-символ
		break;
document.body.style.backgroundColor = (colr.charAt[0] !='#' && i < cL ?'':'#') + colr;

Наверное, это выглядит с первого взгляда сложно, но уже не вызывает отторжения из-за примитивности. Иначе, получается, что мы применяем новейшие технологии сборки, а выразить в коде дружественный интерфейс не в состоянии. Уже потом мы сможем оформить свои пожелания в более совершенном коде, придумать для своих кодов не такой примитивный loadScript и читатель якорей, написать всё это в кофе-скрипте и хранить в своей библиотеке сборки. Ведь к сборкам проектов мы приходим от желания не соглашаться на компромиссы примитивности и просто отображать сложную логику абстракций.

Вариант 1: Closure Compiler

Гугловский Closure Compiler — это инструмент оптимизации JavaScript. Он анализирует код, удаляет ненужные кусочки, а оставшееся — минифицирует. Кроме того, может генерировать Source Map.

Делаем следующие шаги для создания оптимизированной версии скрипта:

  • Скачиваем новейший Closure Compiler;
  • Кладём файл compiler.jar в каталог со скриптами;
  • В командной строке переходим в каталог "scripts/" и выполняем команду, чтобы создать оптимизированный и готовый к выполнению в production файл script.closure.js
java -jar compiler.jar --js script.js --js_output_file script.closure.js
  • Убеждаемся, что index.html связан с созданным файлом, раскомментировав «Option A».

Введение в Source Maps
Когда мы открываем index.html в браузере и смотрим панель Source в инструментах разработчика, имеется ссылка только на оптимизированную версию скрипта script.closure.js; у нас нет способа связи с оригинальным файлом кодов с нужными отступами. Теперь создадим файл карты кодов выполнением следующей команды в каталоге скриптов:

java -jar compiler.jar --js script.js --create_source_map script.closure.js.map --source_map_format=V3 --js_output_file script.closure.js

Обратите внимание, что Closure Compiler использует 2 варианта — --create_source_map and --source_map_format, чтобы создать файл карты script.closure.js.map с Source Map версии 3. Но и это не всё. Чтобы увидеть эффект, добавьте URL исходников к концу скомпилированного файла script.closure.js, чтобы он содержал данные о расположении их.

//@ sourceMappingURL=script.closure.js.map

Теперь просмотр скриптов в браузере через панель разработчика покажет оба файла — оригинал и оптимизированный script.closure.js. Хотя браузер использует оптимизированный файл, Source Map позволяет связать его с исходным кодом.

Попробуйте отладку с точками останова. Наблюдаемые выражения и переменные пока недоступны при просмотре исходников. Будем надеяться, что в будущем они появятся!
Введение в Source Maps

Кириллические пользователи имеют счатье заметить и другой косяк: неотображение символов UTF-8 в файле, подгруженном по маппингу:

      Введение в Source Maps

Вариант 2: Задача GruntJS для JSMin

Если вы уже используете Grunt.js для сборки проектов, то он сейчас пригодится для кодовых карт из программы JSMin. Код будет не только минифицирован, но также будет создана карта кодов. (Надо вспомнить, что работа Grunt версии 0.4 отличается от описываемой в статье версии 0.3. --прим.перев.)

Шаги показывают, как создать оптимизированную версию с плагином JSMin с помощью Grunt.

1. Установите Grunt и запустите (альтернативное свежее описание) в nodeJS gruntfile под названием grunt.js, размещённый в корне каталога "start/".

$ npm install -g grunt
$ npm view grunt version
npm http GET https://registry.npmjs.org/grunt
npm http 200 https://registry.npmjs.org/grunt
0.3.17
$ grunt init:gruntfile

Как работать с Grunt 0.4.x

Если у вас установлена старая версия, но вы хотите обновить её до 0.4.x, то процесс установки будет другим. Прежде всего, удалите старую версию Grunt 0.3.x (если была установлена как глобальная).

npm uninstall -g grunt

Ознакомимся подробнее с установкой задач в Grunt 0.4, так как это надолго будет одним из основных инструментов сборки.

Теперь модуль Grunt в новой версии разделён на несколько модулей — ядро и плагины, чтобы вынести все коды приложений из ядра. В установке участвуют несколько модулей.

Установим интерфейс командной строки как глобальный модуль grunt-cli.

npm install -g grunt-cli

Введение в Source Maps
Для запуска задач в проектах этого недостаточно — в каждом проекте нужно описать задачи в файле Gruntfile. Если раньше он назывался grunt.js, то в новой версии — Gruntfile.js или Gruntfile.coffee. Второй необходимый файл в корне проекта — это package.json со списком зависимостей, использующийся в npm (Node.js package manager).

В каждой задаче в папке проекта инсталлируется локальный модуль grunt.

npm install grunt

Поэтому зайдём в командной строке в папку «start/» и выполним там указанную команду. Как и в 0.3.x-версии, появится папка node_modules и в ней — папка модуля grunt.

Разбрасывание основного кода по проектам сделано с целью возможности запуска разных версий сбрщика на одном компьютере. grunt-cli — всего лишь оболочка, запускающая команду в нужной папке проекта. ( gruntjs.com/getting-started )

Далее, в корне проекта («start/») готовим Gruntfile.js и package.json. package.json будет связан с вашим проектом и в нём описываются зависимости — потребности в плагинах сборщика. Для нашего проекта напишем:

{
  "name": "colors",
  "version": "0.1.0",
  "devDependencies": {
    "grunt": "~0.4.1",
    "grunt-jsmin-sourcemap": "~1.5.6"
  }
}

Вместо последующего пункта 2 для версии 0.3.х понадобится выполнить

npm install grunt --save-dev

, чтобы подтянуть все зависимости из package.json.

2. (Для версии 0.3.х). Установите плагин grunt-jsmin-sourcemap. При этом будет создан каталог node_modules/grunt-jsmin-sourcemap.

$ npm install grunt-jsmin-sourcemap

3. Отредактируйте созданный grunt.js (для версии 0.4 — создайте Gruntfile.js в «start/») так, чтобы он содержал только задачу jsmin-sourcemap — будем поступать максимально просто:

module.exports = function(grunt) {
  grunt.loadNpmTasks('grunt-jsmin-sourcemap');
  grunt.initConfig({
    'jsmin-sourcemap': {
      all: {
        src: ['scripts/script.js'],
        dest: 'scripts/script.jsmin-grunt.js',
        destMap: 'scripts/script.jsmin-grunt.js.map'
      }
    }
  });
  grunt.registerTask('default', 'jsmin-sourcemap');
};

4. Вернитесь к командной строке и запустите grunt:

E:ProjectsnodeJSSourceMaps101start> grunt

Это выполнит задачу jsmin-sourcemap как задачу по умолчанию, сформулированную в файле grunt.js (или Gruntfile.js). В случае успешного результата:

Running "jsmin-sourcemap:all" (jsmin-sourcemap) task
 
Done, without errors.

Далее, будем складывать результаты выполнения в каталог complete-ru, чтобы отличать результаты автора от своих, которые будут различны в основном из-за новой версии Grunt. Это поможет сверить ваши результаты с теми проверенными, что получены на Windows при запуске примеров. --прим.перев.

5. Убедитесь, что в созданном файле Source Map script.jsmin-grunt.js.map прописан файл исходников: "sources":["script.js"].
(На самом деле там прописался "sources":["scripts/script.js"], поэтому следует руками подправить. — прим.перев.)

6. Раскомментируйте Option B, чтобы подключить созданный файл script.grunt-jsmin.js к index.html, и откройте его в браузере.

(Модифицированный файл index-ru.html достаточно вызвать с якорем: localhost/index-ru.html#option=jsmin. — прим.перев.)

В этом примере у нас тоже получился маппинг исходного файла — не зря мы продирались сквозь инсталляцию сборщика. Дальше будет легче, основной инструмент — у нас в кармане.

Как видно и здесь мы наблюдаем косячки сборки, которые затем, если использовать — придётся тексты подправлять серверными скриптами и версию за версией следить за исправлениями. Такая она — разработка с инструментами на ранних стадиях готовности, при этом, очень востребованная рынком.

С Grunt и плагином jsmin-sourcemap процесс сборки создаёт 2 файла: оптимизированный скрипт со ссылкой на маппинг-файл в конце и сам файл карты кодов. Аналогично прежнему варианту, для просмотра исходников понадобятся оба файла.
Введение в Source Maps

Вариант 3: UglifyJS

UglifyJS2 — другой оптимизатор-компрессор JS. Как и в 2 прежних случаях, создаются оптимизированный файл скрипта, добавляется URL кодовой карты и сам файл карты, содержащий соответствия между сжатыми и исходными операторами JavaScript. Для использования выполните в каталоге "start":
1. Инсталлируйте модуль uglify-js (создасстся каталог nocde_module/uglify-js ):

$ npm install uglify-js -g
$ npm view uglify-js version
2.2.3
$ cd scripts/

Введение в Source Maps

2. В каталоге “scripts” выполним команду создания оптимизированной версии и карты:

uglifyjs --source-map script.uglify.js.map --output script.uglify.js script.js

(На этот раз — никакого шаманства руками, всё работает.)

3. В index.html раскомментируйте вариант «Option C».
Введение в Source Maps

Вариант 4: CoffeeScript Redux

Так как к моменту написания статьи оригинальная сборка Coffescript от Джереми Ашкенаса не поддерживала меппинг, был использован клон, работающий с меппингом. В версии Coffescript 1.6.1+ можно использовать оригинальный язык (что, впрочем, не уменьшает других достоинств клона).

Клон этот, кстати, успешно собрал заявленные как цель 12 тыс $ на Кикстартере на дальнейшее развитие.

В первых 3 вариантах требовался только 1 шаг оптимизации. Для языков типа CoffeeScript нужно 2 шага: из CoffeeScript в JavaScript, а затем — в оптимизированный JS. Рассмотрим, как создать многоуровневую кодовую карту — из CoffeeScript и из компилятора CoffeeScript Redux (потому что исходный Coffeescript не поддерживал карт до версии 1.6.1 — прим. перев.).

Шаг 1: из CoffeeScript в простой JavaScript

Перейдите в каталог "start" в командной строке. В следующих шагах будем создавать файл соответствий между оптимизированным и файлом исходных кодов.
1. Установим CoffeeScript с опцией -g возможности глобального вызова.
2. Компилируем script.coffee.coffee в простой JS:

$ coffee -c scripts/script.coffee.coffee

3. Установим CoffeeScript Redux:

$ git clone https://github.com/michaelficarra/CoffeeScriptRedux.git coffee-redux
$ cd coffee-redux
$ npm install
$ make -j test
$ cd ..

4. Создадим файл маппинга script.coffee.js.map, описывающего соответствия между простым JS и исходным CoffeeScript.

$ coffee-redux/bin/coffee --source-map -i scripts/script.coffee.coffee > scripts/script.coffee.js.map

5. Убедитесь, что в самом конце файла script.coffee.js есть URL-адрес карты кодов:

//@ sourceMappingURL=script.coffee.js.map

6. Убедитесь, что файл script.coffee.js.map имеет правильную ссылку на файл:

"file":"script.coffee.coffee", and source file as "sources":["script.coffee.coffee"]

Сделаем вместо работы с клоном кофе-скрипта пример с оригинальным компилятором.
Пункты 1 и 2 — остаются без изменений.
Пункт 3 — пропускаем.
4.

coffee -o script.c -cm script.coffee.coffee

("-cm" — это сокращённые параметры "--compile" и "--map".)
5. Косяки.
C созданием выходного файла — сразу пара багов. 1) файл script.coffee.js не создаётся — вместо него — script.js, затирая вариант из первых примеров. Поэтому создаём файл в отдельном каталоге (способа создать файл с другим именем в рамках одной команды не существует, если не рассматривать потоки в ОС); 2) если каталога нет, создаётся «левый» пустой каталог "/-p/" наряду с требуемым.

Для проверки путей стоит запустить этот промежуточный результат, который будет выглядеть как 6-й пример — несжатый coffeescript, и проверит правильность путей в нём.

Если создаём карту кодов одной командой (а не двумя раздельными), то в конце компилированного файла имеется комментарий вида

/*
//@ sourceMappingURL=script.map
*/

Оказалось, что в Хроме читается комментарий и такого вида.
И «file»: «script.js» и прочие пути в карте кодов тоже менять не понадобилось. Там находится:

  "file": "script.js",
  "sourceRoot": "..",
  "sources": [
    "script.coffee.coffee"
  ],

Для запуска заранее выбрали такое странное имя каталога, script.c, чтобы он хорошо лёг в ранее построенный скрипт.

var lHash = location.hash.substr(1).split('=');
if(lHash && lHash.length ==2 && lHash[0] =='option')
	var optionName = lHash[1];
if(optionName && !parseInt(optionName))
	optionName = {closure:1,jsmin:2,uglifyjs:3,coffeescript:4,typescript:5,'coff':6}[optionName.toLowerCase()];
console.log(optionName);
optionName = optionName ||0;
var loadScript;
(loadScript = function(i){
	var scr = document.createElement('SCRIPT');
	scr.setAttribute('type', 'application/javascript');
	scr.src ='scripts/script.'+ ('|closure|jsmin-grunt|uglify|coffee.min|typescript.min|c/script'.split('|')[i]) +(i?'.':'') +'js';
	document.getElementsByTagName('head')[0].appendChild(scr);
})(optionName);

При параметре 6 или coff будет читаться скрипт из пути scripts/script.c/script.js. Видим, что всё работает без заплаток, несмотря на создание промежуточного файла в каталоге. Хорошая работа автора компилятора!

Так выглядит кофескрипт в отладке Хрома.
Введение в Source Maps
Видно, что Хром всё так же совершенно не понимает utf-8. Установка scr.setAttribute('charset', 'utf-8'); тоже не помогает.

Шаг 2: из простого JavaScript в минифицированный JS

1. Наконец, используем UglifyJS, чтобы сжать JS и создать кодовую карту. На этот раз сборщик примет кодовую карту от CoffeeScript, чтобы мы могли добраться до исходных кодов. Выполните команду в "scripts":

$ cd scripts/
$ uglifyjs script.coffee.js -o script.coffee.min.js --source-map script.coffee.min.js.map --in-source-map script.coffee.js.map

Для нашей ветки примеров вид команды —

uglifyjs script.c/script.js -o script.coffee.min.js --source-map script.coffee.min.js.map --in-source-map script.c/script.map

2. Убедитесь, что файл карты кодов имеет правильную ссылку вида

"file":"script.coffee.min.js"

… и правильные ссылки на исходные коды вида

"sources":["script.coffee.coffee"]

Введение в Source Maps

Пишем в адресной строке

http://localhost/#option=coffeescript

… И видим, что с путём в файле творится неладное. "sources":["script.coffee.coffee"] должен работать, но не заработал. Но удалось увидеть исходный файл, написав (понадобилось переоткрыть браузер)

"sources":["/scripts/script.coffee.coffee"]

Всё же, сказались усложнённые пути с каталогом script.c, и минификатор в связке заработал не так, править пришлось, и эта правка больше похожа на хак сырого продукта.

Вариант 5: TypeScript

TypeScript, как и CoffeeScript, тоже требует 2 этапа: TypeScript > простой JavaScript > минифицированный JavaScript. Поскольку скрипт использует плагин jQuery, нужно будет 2 файла TypeScript с именами script.typescript.ts и jquery.d.ts.

Шаг 1: из TypeScript в простой JavaScript

Перейдите в каталог «scripts» в режиме командной строки и выполните:

$ tsc script.typescript.ts -sourcemap

Команда создаст файл script.typescript.js со ссылкой в конце:

//@ sourceMappingURL=script.typescript.js.map

И в той же команде создаётся файл карты script.typescript.js.map.

Шаг 2: из простого JavaScript в минифицированный JS

Как и для CoffeweScript, следующий шаг использует UglifyJS:

$ uglifyjs script.typescript.js -o script.typescript.min.js --source-map script.typescript.min.js.map --in-source-map script.typescript.js.map

Убедитесь, что ссылки в index.html указывают на правильный файл скрипта: scripts/script.typescript.min.js и откройте его в браузере.
Введение в Source Maps

Карты кодов для SASS

Кроме JavaScript, Chrome в настоящее время поддерживает SASS и SCSS для карт кодов. Для меппинга SASS давайте изменим некоторые настройки в Хроме и затем скомпилируем SASS в CSS с отладочными параметрами.

1. Перед изменением каких-либо настроек обратите внимание, что при наблюдении элемента из окна инструментов разработчика будем видеть только ссылку на CSS. Это не то, что нужно.
Введение в Source Maps
2. Заходим в chrome://flags/.
3. Устанавливаем «Enable Developer Tools experiments» (в русской версии Хрома — «Включить экспериментальные инструменты разработчика»).
Введение в Source Maps
В Windows:

      Введение в Source Maps

4. Открываем Dev Tools -> Setting -> Experiments -> Check “Support for SASS”.
Введение в Source Maps
В Windows:
Настройки (☰) -> Инструменты -> Инструменты разработчика -> Settings (⏣ в правом нижнем углу) -> Experiments -> Support for Sass.

      Введение в Source Maps

5. Компилируем SASS с такими параметрами отладки в каталоге "styles" в командной строке. Этим будет предваряться каждый набор правил с @media -sass-debug-info

$ cd styles/
$ sass --debug-info --watch style.sass:style.css

6. Убедитесь, что окно Developer Tools переоткрыто и страница перезагружена.
7. Теперь, когда проверяем элемент в Dev.Tools, будем видеть доступ к SASS-файлу.
Введение в Source Maps
Кроме простого просмотра SASS, если запущен LiveReload в фоне, то при изменении SASS-файла страница тоже будет изменяться.

Теперь — откроем проект в Firefox и посмотрим через Firebug. В нём тоже будет доступен просмотр SASS-файла.
Введение в Source Maps

Информация о кодовых картах

Если мы посмотрим любой *.map файл, он будет содержать сопоставление информации между исходным файлом и результирующим. Структура, как правило, содержится в формате JSON по спецификации карт версии 3. Обычно, имеется 5 свойств:
1. version: версия карты (обычно 3).
2. file: имя выходного файла.
3. sources: имя исходного файла.
4. names: символы, используемые для соответствий.
5. mappings: данные соответствий.
Введение в Source Maps

Дополнительные ссылки

Карты кодов всё ещё находятся в стадии активной разработки, но уже есть некоторые заметные ресурсы в Сети. Обязательно посмотрите такие ссылки, чтобы узнать больше.

Заключение

Введение в Source Maps
Надеюсь, что практика использования нескольких компиляторов показала потенциал карт кодов. Хотя функциональность сейчас ограничена, в будущем есть основания ожидать возможности полноценной отладки, в том числе, в виде доступа к переменным и выражениям.

Введение в Source Maps 
 
Автор: Sayanee Basu, независимый разработчик из Сингапура. В её профиле описано знание технологий Ruby и связанных с ним сахарных метаязыков. Отсюда — интерес к сырцовым картам.
 
 
Можно согласиться с автором, что «функциональность ограничена» и сказать больше — почти в каждом примере присутствовали баги с путями к файлам. Имеем состояние сырой технологии; отдалённая аналогия — примерно так было с nodeJS порядка года назад. Но объём доработок не такой большой, вопрос не года, а месяцев, и что вселяет надежду — часть багов лежит в подконтрольных кодах, написанных на nodeJS. При большом желании там можно разобраться. Но уровень гиковости для работы с этой технологией должен быть таким же, как у тех, кто ставит альфа-версии браузеров, не для развлечения, а для дела.

(Следующие вести с полей будут видимо, через пару месяцев про Firefox с его умением работать со всем этим устаканивающимся хозяйством.)

Нужно ли с этим работать сейчас? Если есть большое желание перейти на Coffeescript, то время для него уже настало. Уже сейчас можно получать неоценимый опыт отладки проектов, когда раньше приходилось работать фактически с 2 языками, помня, что отлаживать придётся JS.

Если уже используется Grunt, то для того, чтобы перейти на Кофе и SASS — сейчас дистанция вхождения стала ещё короче. Но, судя даже по примерам, надо быть готовым с головой окунуться во весь стек технологий, ища решение при выявлении багов сборки. Хорошо видно, что баги будут активно исправляться — через поддержку надстроечных языков проходит вектор интересов нескольких крупных игроков рынка, которые просто так недоработки не оставят, потому что чувствуется дыхание догоняющих, а финиш близок.

1) Using Source Maps with TypeScript, Aaron Powell, Oct 3 2012;
2) github.com/mozilla/source-map — This is a library to generate and consume the source map format.
3) Happy debugging with JavaScript source maps by James Allardice, 25 January 2013.
4) bower.io/ — альтернативный сборщик от Twitter.
5) kevinpelgrims.com/blog/2011/12/28/building-coffeescript-with-sublime-on-windows
6) sourcemap.litcoffee.
7) github.com/evanw/node-source-map-support

Автор: spmbt

Источник

Поделиться

* - обязательные к заполнению поля