Как стать автором
Обновить

Комментарии 12

Телепортировали меня в 2013, тогда как раз был популярен этот компилер и проекты с goog.
Но спираль всё же развернулась, теперь TS силен и много проектов на нем, вот и до Closure Compiler докаталась волна.
Вообще забавно, с одной стороны исходниками, а не каким-нибудь байт-кодом скрипты распространяются в том числе чтобы код видеть, но во благо оптимизации, а иногда обфускации, оно всё же пережимается в нечто среднее, из которого исходный код особо не восстановишь, особенно после этого интструмента, весить становится мало, да, но ощущение что где-то по пути мы обманули самих себя. А потом ещё когда map файлы… в общем спираль крутится.
Тоже когда то давно баловался google closure compiler и основная причина почему отказался от него это очень медленная скорость сборки, которая занимала несколько минут, в то время как browserify делал это за несколько секунд. Все таки -5% к размеру бандла не стоят +50% к времени разработки.

Но еще меня интересует почему Яндекс считает что поддерживать старые браузеры важнее чем поддерживать самые популярные браузеры? Я имею ввиду что TS может сам скомпилировать в ES2015, rollup/webpack собрать c treeshaking без babel трансформаций, terser минифицировать с учетом оптимизаций ES2015. И все это будет весить гораздо меньше транспилированного кода и работать в 3 раза быстрее на 80% самых популярных браузерах. А для старых сделать второй бандл на es5 с трансформами babel и полифилами.
Подозреваю, как раз из-за скорости билда. Бабель-то просто отбрасывает типы, не проверяя, чем сокращает время сборки.

ES2020 Private class field proposal https://github.com/tc39/proposal-private-methods
ну или хотя бы так:


const MY_FANCY_PRIVATE_FIELD_NAME = Symbol();

class MyFancyClass {
  [MY_FANCY_PRIVATE_FIELD_NAME] = 'my-fancy-value'
  #orUseNewestES2020feature = 'yeah'
}

babel скомпилит, terser оптимизрует, closure заинлайнит значение если надо

Круто, что у инженеров есть возможность улучшать сторонние технологии и контрибьютить в опенсорс. Возможно кто-то ещё найдет пользу в такой оптимизации.


Интересно, почему за столько лет в Яндекс не родился свой инструмент уровня Google closure compiler без всех вот этих вот его недостатков? Вроде тьма сервисов использует JS и есть возможности для найма толковых разработчиков.

НЛО прилетело и опубликовало эту надпись здесь

Спасибо, интересная статья.


А насколько это замедлило вам сборку? В начале статьи упомянуто, что перешли от ts-loader на babel, в том числе, из-за скорости сборки. А теперь у вас в пайплайне и ts, и babel

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

На картинке в статье этот трансформер (который использует typescript) — именно что часть сборки. Результат трансформера подается на вход бабелю.

сборка замедлилась, но в пределах погрешности (20-30 секунд)
я запускаю этот дополнительный loader только для продовой сборке, поэтому это не очень критично

Как минифицировать приватные поля на привычном стеке и в JS тоже:


  • Заменить в коде
    private fieldName = 'value';
    на
    #fieldName = 'value';

Babel преобразует это в код, которых очень хорошо минифицируется обычным Terser’ом.

Проблема в том, что по-хорошему надо минифицифицировать не только приватные поля, а вообще все, за исключением тех, которые должны быть доступны через публичное API вашей библиотеки. Поэтому и сидим по-прежнему на closure compiler, который переименовывает вообще всё + Object.defineProperty('originalName', ...) для того, чтобы внешний код смог достучаться до избранных апишек. Грустно, конечно, что приходится использовать убогую систему типов closure compiler'а и терять кучу функциональности IDE, завязанную на typescript, но выигрыш в размере колоссальный.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий