Google Closure Compiler в деталях
Этот раздел посвящен Google Closure Compiler.
Чтобы его написать, мне пришлось буквально разобрать компилятор по косточкам, благо все сырцы в наличии есть. И, как оказалось, оно того стоило.
Инструмент мощный, сложный (поначалу), парой слов тут не отделаешься. Надеюсь, что после прочтения данного раздела он станет для вас простым.
|
1. можно ли как-то заставить гугл компилятор(или только переписав изрядно JAVA сорцы) при компиляции запретить некоторые функции javascript на свое усмотрение (или даже методы объектов), например запретить использование eval или document.getElementByID
2. можно ли задать ему шаблон, который нужно использовать в момент минификации. Например, попросить префиксировать все функции/объекты словом "development_"
чтобы поддерживались альтернитивные синтаксисы функций function myFunction -> function development_myFunction и myFunction: function() -> development_myFunction: function()
спасибо
1. Да, можно, причем никаких патчей для этого не нужно. Свой проход компилятора.
Причем, этот проход можно добавить в качестве опции (там есть такая, свои проходы) в MyCompilerRunner, т.к. он независим.
2. Шаблон - нет, операции идут над деревом кода. А вот создать аналогичные функции с development_ - конечно, можно. Похожие действия выполняются в проходе, обрабатывающем exportSymbol.
Никак не могу найти, как отключить перенос строк или указать побольше (в YUICompressor-е для этого есть флаг --line-break). Подскажите, если кто знает.
Написан же флаг, во введении --formatting PRETTY_PRINT
При этом флаге он вообще все переносит, а нужно наоборот, что бы все в одну линию было.
В одну линию - по умолчанию ведь ?
По умолчанию бьётся на строки где-то по 550 символов длиной
Илья, низкий Вам поклон за проделанную работу. Всё очень доступно и интересно написано. Прочел все статьи.
Однако поблагодарить вас за этот труд я считаю нужным!
Искренне благодарен. Спасибо.
в личный список избранных руководств! низкий поклон за проделаную работу
Проделанная работа вызывает изумление и восторг!
Илья, огромное вам человеческое спасибо!
интересная статья ! +
Здравствуйте. Вопрос такой: можно ли как то декомпилировать этот код? То есть хотя бы короткие пременные вернуть в прежний вид, или хотя бы как то теоритически объясните как возможно привести закомпиленный код в читабельный вид.
На следующем примере, за счет инлайнинга констант closure compiler увеличивает размер исходника почти в три раза (вообще, на сколько угодно, зависит от длины строк bigString1 и bigString2):
var bigString1 = "....."; var bigString2 = "....."; return { all: bigString1 + " " + bigString2, bs1: bigString1, bs2: bigString2, bs1LC: bigString1.toLowerCase(), bs2LC: bigString2.toLowerCase(), }Он умеет сжимать CSS? И что вообще есть для сжатия CSS? Что лучше сжимает?
Даже с ADVANCED_OPTIMIZATIONS сэкономил всего 7%. Т.е. смысла использовать нету.
Если изначально код нормально написан то там нечего сжимать.
Правда packer сжал почти на 50%. Но там закодирование стоит, без него только на 65%, но все равно на много лучше гугла.
Странно очень.
Без всяких флагов сжал из 352905 байт в 123744. А нормально написанный код как раз имеет не малый размер за счет комментариев кода.