все форумы все темы добавить тему
Ошибки JS после упаковки
Собственно сабж, после применения модуля js_css_compressor javascript выдает ошибки, которые невозможно отдебажить из-за того, что всё упаковано-перепаковано.
 
Как быть ?
Обычно это происходит из-за отсутствующих точек с запятой в конце строк. Пока строки не объединены - JS автоматически их проставляет, после же объединения это приводит к ошибкам.
Найти такой косяк несложно - просто надо объединенный файл разбивать на строки до тех пор, пока искомая строка не будет локализована.
А парсер точно не лох?
Потому что у меня сейчас получается что он наоборот уберает ; в некоторых местах.
Вот файлы, которые по какой-то причине не пакуются:
http://dev.hottury.in.ua/backup/fuckingfuck/
Я так понимаю парсер их неправильно разбирает.
Я чуток ошибся. Я не пакую.
Вот настройки модуля:
 
Включить
Упаковывать файлы JavaScript и CSS для ускорения загрузки сайта
Да
 
Сжатие CSS
Уменьшать размер файлов за счет удаления неиспользуемоых символов
Да
 
Сжатие JS
Уменьшать размер файлов JavaScript за счет обфускации
Нет
 
Проверять актуальность
Проверка актуальности кэша замедляет выполнение но позволяет избежать ошибок при обновлении файлов
Да
 
Тип объединения
1 - объединять файлы в пределах модуля. 2 - объединять файлы в пределах страницы
1
 

Тоесть косяк возникает на этапе вытягивания скрипта в строку.
Например, конструкция /\?/ после того, как проходит через парсер превращается в /\/ и ясное дело дает ошибку.
Что-то у меня не подтвердилось: и файл swfobject.js отдельно и все файлы скопом объединились корректно - /\?/ осталась на месте.
Вот что я подаю на вход:
http://dev.hottury.in.ua/backup/bad/in/
Вот что получаю на выходе:
http://dev.hottury.in.ua/backup/bad/out/
 
И тут же ошибка:
SCRIPT1002: Синтаксическая ошибка
6c608f940d21b97a6e2533b70e3c9dd0.js?, строка 1 символ 149242
Вообще странное поведение... все файлы по отдельности кодирует нормально, в различных сочетаниях - тоже, а все скопом, почему-то, неправильно... надо будет пристально поизучать этот "феномен"...
Вот и я тоже не понял почему так.
Видимо парсер все таки немножко лох.
Я подозреваю что это из-за комментариев в файлах, там в некоторых местах они в перемешку с кодом идут, типа:
var some = something; //comment
Не должно бы. Как я уже заметил выше, по отдельности файлы преобразовывались нормально. Ломаются только при достижении некой критической массы. В моем случае начинали неправильно обрабатываться элементы \s в регулярных выражениях... можно предположить, что происходит какое-то неявное преобразование переменной в php... в общем, надо будет с отладчиком пройтись. Библиотека эта не моя и с тех пор новых версий не было. Так что либо глюк исключительно редкий, либо я ее как-то неправильно использую.
В общем, виноват оказался php - если в строке встречаются вперемешку виндовые и юниксовые переводы строки, то у интерпретатора напрочь сносит крышу - он начинает достаточно вольно обращаться с этой строкой - где-то работает с ней как с бинарной последовательностью, а где-то - как с текстом. Причем, это не зависит от алгоритма преобразования (я попробовал и регулярные выражения и строковые функции - реакция одинаковая).
 
Как только я привел все Ваши файлы к единой кодировке - проблема исчезла.
спасибо, а как вы это сделали?
у меня они вроде все в UTF8
Речь не о самой кодировке, а о символах перевода строки. В юниксе это \n, в windows - \r\n. У Вас же в разных файлах были разные.