Angular: Используйте Closure Compiler с автономным компилятором шаблонов

Я думаю, что мне больше всего нужно ваше руководство, это то, где и как это вписывается в более крупный процесс сборки angular.
Хотим ли мы (1) построить сам angular как минифицированный внешний пакет? или (2) скомпилировать код пользователя angular + в единый пакет? В последнем случае нам нужно будет интегрироваться в gulp или что-то еще.

Мы распространяем пакеты Angular, такие как ES5 со встроенным загрузчиком модулей UMD.
Однако было бы невозможно снова разобрать это на части, чтобы встряхнуть дерево.
это, так что наш план был №2.
Я не уверен, что мы должны заниматься созданием плагинов для нескольких популярных
инструменты сборки пользовательского пространства; другие в сообществе это подберут. Я думаю
проще "npm run build && npm run closure-compiler" со сценариями оболочки
на данный момент достаточно.

В понедельник, 9 мая 2016 г., в 11:26 Эван Мартин [email protected]
написал:

Я думаю, что мне больше всего нужно ваше руководство, это то, где и как это вписывается в
более крупный угловой процесс сборки.
Хотим ли мы (1) построить сам angular как минифицированный внешний пакет? или
(2) скомпилировать angular + пользовательский код в один пакет? В последнем
случае нам нужно будет интегрировать в gulp или что-то еще.

-
Вы получаете это, потому что вы являетесь автором темы.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/angular/angular/issues/8550#issuecomment -217947352

К вашему сведению @jeffbcross, возможно, это может сделать вашу демонстрацию PWA для ввода-вывода

Да, было бы здорово, если бы у нас все заработало к концу этой недели.

Некоторые заметки из хаков, которые мне приходилось делать до сих пор, в надежде, что другие смогут воспроизвести:

Closure Compiler не обрабатывает весь синтаксис модуля ES6 и не рекомендует его использовать. Итак, наша стратегия до сих пор заключалась в использовании синтаксиса goog.module . Это не вариант --module для tsc , поэтому мы используем tsickle, чтобы переписать его. Это означает, что angular и его зависимости должны быть отправлены как «Closure ES6».

Необходимо создать компилятор закрытия из HEAD, см. Https://github.com/google/closure-compiler/blob/master/README.md#building -it -self

Чтобы встроить angular в закрытие ES6, у меня есть локальные правки в инструменте ngc для запуска аннотации закрытия tsickle и convertCommonJsToGoogModule. См. Https://github.com/alexeagle/angular/tree/closure_hack2
Создайте angular обычным способом с помощью ./build.sh а затем сделайте пакеты устанавливаемыми с помощью for pkg in $(find dist/packages-dist -name package.json); do sed -i .bak 's/\$\$ANGULAR_VERSION\$\$/2.0.0-rc.2-snap/g' $pkg; done

Чтобы встроить rxjs в закрытие ES6, у меня есть локальные правки в https://github.com/alexeagle/RxJS/tree/closure - затем запустите npm run build_es6 чтобы получить нужные файлы в dist/es6 . Затем npm run generate_packages для копирования в package.json .

Нам нужна модификация tsickle для обходного пути https://github.com/ReactiveX/rxjs/issues/1703 - см. Https://github.com/angular/tsickle/tree/closure

Теперь я делаю пример приложения. Снимок на https://github.com/alexeagle/closure-compiler-angular-bundling
В каталоге vendor я уже установил локально созданный closure compiler.jar, пакеты angular2, rxjs и tsickle с чем-то вроде
npm install ../angular/dist/packages-dist/{common,compiler_cli,compiler,core,platform-browser,platform-server}
npm install ../rxjs/dist/es6

Таким образом, вы можете просто npm install и npm run build чтобы воспроизвести пакет закрытия :)

Итак, мне нужно было бы установить Java JRE, чтобы связать приложение Angular2 hello world?

Closure Compiler - лишь один из вариантов
tree-shake / bundle / Es6-to-5 / minify pipeline. Если вы выберете закрытие
вариант компилятора, вы сейчас выбираете зависимость JRE. Но есть еще JS
версия в разработке:
https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/gwt/client/GwtRunner.java

13 мая 2016 г. в 9:44 dpsthree [email protected] написал:

Поэтому мне нужно было бы установить Java JRE, чтобы связать привет, мир
Приложение Angular2?

-
Вы получаете это, потому что вы являетесь автором темы.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/angular/angular/issues/8550#issuecomment -219096815

Я написал несколько заметок о хитростях, необходимых для работы. https://docs.google.com/document/d/17m1GwzXraKgbCkCmH1JnY9IZzPy4cqlpCFVhvlZnOys/edit

Мы воспроизвели работу @alexeagle и более свежую версию Angular. Весь процесс сборки является автоматическим, поэтому вы можете отслеживать все, от источника до конечного результата. Вы можете увидеть это в действии на https://github.com/lucidsoftware/closure-typescript-example. Инструкции по запуску примера можно найти в README для репозитория примера. Для проекта существует контейнер Docker, поэтому его может попробовать практически любой желающий.

В приведенном выше примере используются Angular 2, clutz и tsickle. Closure JS используется в Angular 2 TS, который скомпилирован в JS, совместимый с Closure.

Изменения, которые мы внесли в зависимости, чтобы заставить это работать, во многом такие же, как у Алекса. Мы добавили несколько изменений и несколько изменений, которые больше не нужны. Тем не менее, основная идея остается той же. Мы используем модифицированный ngc или tsickle в Angular 2 и его зависимостях для создания версий этих зависимостей, совместимых с Closure.

Компилятор закрытия

Строить из головы больше не нужно. Просто используйте одну из версий с июня или июля.

Угловой

https://github.com/lucidsoftware/angular/tree/closure-bundle

Основная часть работы в исходном коде Angular 2 заключается в изменении ngc для создания компилируемых js в Closure путем добавления нескольких шагов tsickle в tsc-wrapped. Есть несколько приемов, через которые мы перескакиваем, чтобы использовать измененный источник в качестве входных данных для компилятора TypeScript в одном из проходов tsickle. В противном случае это довольно просто.

Мы также изменяем определенные модули Angular, чтобы они были скомпилированы в JS, совместимый с Closure, помещая блок angularCompilerOptions в tsconfig.json, например, так

"angularCompilerOptions": {
  "googleClosureOutput": true
}

Затем, когда вы запустите build.sh эти модули получат желаемый результат.

Файл тестовой утилиты, использующий selenium-webdriver, изменен, потому что selenium-webdriver отсутствует, и мы не хотели делать его совместимым с закрытием.

RxJS

https://github.com/lucidsoftware/rxjs/tree/closure-hack

Процесс сборки RxJS изменен для сборки с помощью Makefile из нашего проекта. Примерно половина процесса сборки выполняется в JS, а другая половина - в Make. Это довольно неприятно.

Единственные другие изменения, помимо цели сборки, - это несколько мелких вещей, которые заставят RxJS скомпилировать с TypeScript и Closure.

символ-наблюдаемый (зависимость RxJS)

https://github.com/lucidsoftware/symbol-observable/tree/closure

RxJS теперь зависит от некоторого кода, который раньше был частью исходного кода RxJS, а теперь является его собственным модулем. Мы модифицируем этот модуль (который является JS), чтобы он был совместим с компилятором Closure. Файлов всего два, так что я сделал это вручную.

серп

https://github.com/lucidsoftware/tsickle/tree/ignore-type-comments

Мы модифицируем Tsickle двумя способами:

1. Добавьте параметр --ignoreTypesInComments. Это предотвращает появление ошибки tsickle при обнаружении jsdoc в комментариях. Это необходимо для компиляции RxJS, который имеет кучу комментариев jsdoc.
2. Измените pathToModuleName чтобы CLI был таким же, как pathToModuleName мы используем в ngc. Таким образом, модули будут называться одинаково при запуске через tsickle или ngc. Это должно быть зафиксировано в восходящем направлении, потому что текущий pathToModuleName иногда дает недопустимые имена goog.module.

• запустите tree-shaker, чтобы удалить модули ES6, недоступные из точки входа, в нашей демонстрации мы показали свертку
• запустите сборщик, чтобы сократить импорт модулей до объявлений в одном файле; мы показали system.js
• ниже уровня ES5 - мы показали это с помощью TypeScript
• minify, чтобы сократить имена символов, мы использовали uglify.

Хотя он, возможно, не может соответствовать окончательному размеру вывода компилятора Closure, webpack 2 (с использованием загрузчика машинописного текста и стандартных плагинов оптимизации) предоставляет вам все эти шаги.

Я бы сказал, что преимущество разработчиков, которые уже используют (смею сказать _requiring_) такой инструмент, как webpack в своем стеке, и, следовательно, не нужно добавлять больше (взломанных) зависимостей, более важно, чем сбрасывать лишние байты в окончательной полезной нагрузке.

Хотелось бы услышать ваши мысли!

@jjudd большое спасибо за публикацию вашего репо и этих заметок, это действительно полезно.

У вас есть уменьшенный размер приложения, которым вы можете поделиться? Возможно, используется сжатие Brotli, поэтому у нас есть сравнение яблок с яблоками с примером hello world closure-ng2 (который был 26,2k)

@JamesHenry: мы согласны с тем, что webpack 2 - это путь вперед для большинства разработчиков. Компилятор закрытия - это экспертный инструмент, и я сомневаюсь, что мы сможем обернуть его в пакет, который «просто работает» для разработчиков, которые еще не знакомы с отладкой неясных способов, которыми его ADVANCED_OPTIMIZATIONS может разрушить ваше приложение.

@alexeagle В настоящее время мы работаем над тем, чтобы заставить это работать с ADVANCED_OPTIMIZATIONS. Когда мы получим эту работу, я опубликую несколько тестов.

Преобразовал проблему 1, описанную выше, в отчет об ошибке.

компилятор закрытия теперь доступен в npm на чистом javascript: https://www.npmjs.com/package/google-closure-compiler-js

Хотел предоставить обновление:

У нас есть репозиторий примеров и бета-редактор Lucidchart, работающий с расширенной оптимизацией. Мы провели небольшой тест, используя нашу версию с простой оптимизацией, и наша версия с расширенной оптимизацией выйдет сегодня или завтра.

Версия Angular, используемая в репозитории примера, была обновлена ​​до RC5 (HEAD по состоянию на вторник, 16 августа).

Репозиторий примера и сопровождающий его контейнер Docker были обновлены на случай, если кто-то захочет попробовать его. Вот ссылка на пример репозитория https://github.com/lucidsoftware/closure-typescript-example

Размеры связки

Окончательный размер пакета для примера проекта, использующего расширенную компиляцию, указан ниже. Примечание: пример репо включает код, идущий от js -> ts с использованием clutz, а затем ts -> js с использованием tsickle. Это немного больше, чем просто приложение Hello World.

Uncompressed: 112K
Brotli quality 10: 29K
Gzip: 34K

Заметки о том, как заставить это работать

Вот заметки о том, что потребовалось для работы расширенной оптимизации. Если я что-то забыл, я собираюсь предоставить ссылки на все наши форки, в которых есть все наши коммиты.

Пример репо

Файлы Externs для Zone, Reflect и Jasmine были включены в процесс сборки, поэтому эти вызовы функций не были переименованы.

Чтобы обойти ошибку компилятора Closure, когда статические методы теряются, у нас есть действительно хакерская команда sed, которую мы запускаем для встроенных файлов Angular js, заменяя все строки, которые включают ключевое слово static, строкой, которой предшествует / ** @nocollapse * / . Вот ссылка на ошибку закрытия: https://github.com/google/closure-compiler/issues/1776

Угловой

Самое большое изменение, которое мы внесли в Angular, - это использование аннотированного вывода Tsickle во время компиляции. Мы думали, что сделали это в прошлый раз, но у нас была ошибка, из-за которой аннотированный вывод выбрасывался: D

Было несколько мест, где Angular называет функции строками. Эти функции упоминались в других местах с использованием точечной нотации. Соответственно, одни ссылки были переименованы, а другие нет. Мы изменили Angular, чтобы везде использовать точечную нотацию для этих функций, чтобы они всегда переименовывались.

Мы также обновили Angular / Tsickle, чтобы не комментировать файлы .d.ts.

Мы заставили Angular хорошо работать с ES6, поэтому он работает в некомпилированном режиме. Мы изменим некоторые места, где .apply использовался в конструкторе, чтобы использовать ключевое слово new.

Цикле

Мы исправили ошибку в tsickle, из-за которой интерфейс командной строки не всегда включал все исходные файлы во время аннотации. Список имен файлов из программы TypeScript должен был использоваться, вместо этого мы использовали другой список имен файлов.

Ссылки на все наши форки проектов, чтобы эта работа работала

Угловой: https://github.com/lucidsoftware/angular/tree/closure-bundle
Цикле: https://github.com/lucidsoftware/tsickle/tree/closure-bundle
RxJS: https://github.com/lucidsoftware/rxjs/tree/closure-hack
наблюдаемый символ: https://github.com/lucidsoftware/symbol-observable/tree/closure
Clutz: https://github.com/lucidsoftware/clutz

Итак, у нас есть пара примеров такой работы, плюс мы используем JSCompiler внутри Google, поэтому у нас есть много приложений, которые это делают (хотя и используют систему сборки Bazel и некоторые еще не выпущенные правила Bazel).

@robwormald @mprobst стоит ли нам попытаться упаковать это так, чтобы было легче воспроизводить это для внешних пользователей? Я не думаю, что мы можем заявить об успехе и закрыть этот вопрос.

Компилятор замыкания JS выглядит действительно круто. Однако я сталкивался с проблемами, когда процессу не хватало памяти при нацеливании на проекты AOT среднего размера с помощью Rollup. Вы сталкивались с этим при тестировании?

Однако версия для Java, похоже, не страдает от этой проблемы.

https://github.com/google/closure-compiler-js/issues/23

Я тоже это слышал. Нам пришлось вызвать узел с помощью
--max-old-space-size = 4096, чтобы некоторые инструменты работали в прошлом.

Вторник, 20 сентября 2016 г., 11:27 Торгейр Хельгевольд [email protected]
написал:

Компилятор замыкания JS выглядит действительно круто. Однако я видел проблемы
где процессу не хватает памяти с ориентацией на AOT среднего размера
проекты. Вы сталкивались с этим при тестировании?

Однако версия для Java, похоже, не страдает от этой проблемы.

Google / закрытие-компилятор-js №23
https://github.com/google/closure-compiler-js/issues/23

-
Вы получаете это, потому что вас назначили.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/angular/angular/issues/8550#issuecomment -248389501,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAC5I_FDlMdHvHO2YCvypXju9wR8onzuks5qsCWmgaJpZM4IaZIi
.

Я попробовал max-old-space-size с 8000 и 14000 на Mac с 16 ГБ оперативной памяти, но у меня все еще не хватало памяти в моем образце проекта.
Хотя версия Java работает.

ох, кажется, это плохо :)
не могли бы вы сообщить об ошибке на https://github.com/google/closure-compiler/issues

Вторник, 20 сентября 2016 г., 11:52 Торгейр Хельгевольд [email protected]
написал:

Я пробовал max-old-space-size с 8000 и 14000 на Mac с 16 ГБ оперативной памяти,
но в моем образце проекта все еще не хватало памяти.
Хотя версия Java работает.

-
Вы получаете это, потому что вас назначили.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/angular/angular/issues/8550#issuecomment -248396986,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAC5I25uOXJ-Pt8a9WzQQUO1zRx4j1YUks5qsCthgaJpZM4IaZIi
.

Да, у меня уже есть активная проблема
https://github.com/google/closure-compiler-js/issues/23

@thelgevold, которая может быть связана с ошибкой Typescript ... попробуйте создать ночную сборку Typescript ... (к сожалению, ngc не поддерживает TS 2.1, поэтому вам придется возвращаться назад и вперед между этим и 2.0.2).

@qdouble Хм интересно .. Вы говорите, что это может быть связано с JavaScript, созданным TS 2.0.2?
Поскольку к тому времени, когда мой код входит в состав компилятора объединения / закрытия, он уже находится в формате JS.

@thelgevold ах, есть ошибка, которая может помешать созданию вашего кода, если у вас много элементов управления формой и прочего с 2.0.2 ... если ваши файлы уже являются JS до того, как вы столкнетесь с ошибкой, тогда это может быть что-то еще ... но я полагаю, вы могли бы попробовать использовать Typescript каждую ночь, чтобы превратить его в JS и посмотреть, имеет ли это какое-либо значение.

Привет, ребята, все это звучит очень интересно, и мы изучаем это, чтобы улучшить работу нашего веб-сайта. Каков текущий статус пользовательских сборок Angular, которые вы делаете? Будете ли вы делать сборку для Angular v 2.0.0?

Я постараюсь получить обновленную информацию об этом для ngEurope ...

В пятницу, 7 октября 2016 г., 01:48 Джерард Ламусс [email protected]
написал:

Привет, ребята, все это звучит очень интересно, и мы изучаем это
для повышения производительности нашего веб-сайта. Каков текущий статус
пользовательские угловые сборки, которые вы делаете. Вы будете делать сборку для
Angular v 2.0.0?

-
Вы получаете это, потому что вас назначили.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/angular/angular/issues/8550#issuecomment -252186017,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAC5I1TZZEGiuBu8zJe2BtYEzilr-VPHks5qxgdTgaJpZM4IaZIi
.

Привет, @ u12206050 , пару выходных назад я

Я больше не работаю над этим активно, но другая команда здесь, в Lucid, с которой я разговаривал сегодня, хочет в ближайшее время заняться этим. Если у меня будут еще одни бесплатные выходные, я бы хотел перебрать его на 2.0.1. Так что тот, кто доберется до этого первым.

А пока, если вы хотите получить дополнительную информацию об этом, вы можете проверить сообщение в блоге, которое мы написали об этом по адресу https://www.lucidchart.com/techblog/2016/09/26/improving-angular-2 -время загрузки /. Надеюсь, это поможет.

Если у вас возникнут какие-либо проблемы и вы захотите ответить мне на несколько вопросов, пожалуйста, не стесняйтесь. Тем не менее, это, вероятно, будет немного приключением, если подключить его к вашей системе сборки. Удачи! :)

любое обновление от ngeurope случайно?

после осознания того, что встряхивание дерева webpack2 _не_ реэкспорт дерева встряхивает, а angular требует импорта из реэкспорта, это довольно облом

моя очевидная мысль была о, мурашки по коже! думал, что я буду использовать ngc -> tsickle -> webpack -> gcc advanced (вместо просто ngc -> webpack -> gcc simple) только для реализации tsickle, конвертирующего import / require в goog.require, поэтому нет простого веб-пакета (или любой другой сборщик, не связанный с Google, действительно) интеграция здесь в настоящее время

angular core + forms + router + platform-browser + common занимает ~ 30% нашего основного пакета с ngc + webpack2. это ~ 100 КБ минифицировано и сжато, ой

Я бы хотел увидеть, как tsickle работает с webpack, поскольку очевидно, что даже команда angular cli считает, что webpack - отличный выбор. Я открыт для любых предложений по этому поводу. В противном случае я более подробно рассмотрю работу @ngtools/webpack ?)

https://docs.google.com/presentation/d/1SaHtM1_mpBZuN74wxAJSPQRB0sPbWRSJPQZsxx4_BpE/preview

В их ленте Twitter, кажется, есть контент.

Получите Outlook для And roidhttps: //aka.ms/ghei36

Пт, 28 октября 2016 г., в 00:52 +0200, "Стив Сьюэлл" < [email protected] [email protected] > написал:

любое обновление от ngeurope случайно?

после осознания того, что встряхивание дерева веб-пакетов не вызывает реэкспорта, а angular требует импорта из реэкспорта, это довольно облом

моя очевидная мысль была о, мурашки по коже! думал, что перенаправлю ngc -> tsickle -> webpack (вместо просто ngc -> webpack) только для реализации tsickle, преобразуя import / require в goog.require, поэтому в настоящее время здесь нет простой интеграции с веб-пакетом

angular core + forms + router + platform-browser + common занимает ~ 30% нашего основного пакета с webpack2. это ~ 100 КБ минифицировано и сжато, ой

открыт для любых предложений по этому поводу. в противном случае я более подробно рассмотрю работу @j juddhttps: //github.com/jjudd , но мне не хотелось бы тратить время, если официальное решение уже не за горами.

Вы получаете это, потому что подписаны на эту беседу.
Ответить на это сообщение непосредственно, просмотреть его на Gi tHubhttps: //github.com/angular/angular/issues/8550#issuecomment -256791543 или приглушить й readhttps: //github.com/notifications/unsubscribe-auth/AAABN_sAdZ1RDtPIk1Zt4QJr7oUdg723ks5q4SqbgaJpZM4IaZIi.

Обновление: у нас была серьезная дискуссия на ngEurope с @robwormald, @hansl и другими.
@ pkozlowski-opensource скептически относится к тому, что внешнее сообщество примет новую цепочку инструментов, а не улучшит существующую.
Итак, я думаю, что первым шагом является то, что angular-cli будет работать над улучшением webpack, чтобы он работал лучше.

В то же время мне хотелось бы иметь канонический начальный проект, демонстрирующий использование компилятора замыкания. @ steve8708 Я не уверен, что вы имеете в виду, goog.require нарушает сборщик, поскольку компилятор закрытия _является_ сборщиком. В его выводе нет операторов goog.require . @jjudd. Кто-нибудь в Lucidchart заинтересован в сотрудничестве, чтобы развернуть наши хаки и дать возможность внешнему сообществу воспроизвести приложение 26k ng2?

@alexeagle в настоящее время мы используем webpack для множества вещей - связывания, разделения кода, предварительной обработки, линтинга, хеширования, сжатия и многого другого, аналогично тому, что делают angular CLI и многие популярные стартеры angular + webpack с открытым исходным кодом.

Я бы очень хотел сохранить webpack для всего, что он делает (особенно. Bc, мы можем использовать множество плагинов сообщества, чтобы сделать некоторые сложные задачи простыми и настраиваемыми), а не заново реализовывать все, что мы делаем в настоящее время (скажем, с помощью gcc + gulp).

Я бы хотел просто иметь возможность просто поменять tsickle на tsc, чтобы добавить аннотации jsdoc во время транспиляции, необходимые для минификации в расширенном режиме (в настоящее время мы используем плагин gcc webpack в простом режиме для минификации)

Тем не менее, я очень благодарен за ваше обновление и очень хочу отслеживать прогресс, который команда angular-cli делает с их набором инструментов для веб-пакетов!

@ steve8708, с какими инструментами вы хотите работать с аннотированным закрытием кодом ES6 goog-module'd, прежде чем передавать его в свой плагин gcc?

@alexeagle Спасибо за обновление. Я поговорю с людьми здесь и посмотрю, какой будет интерес.

Что касается примера, то, о чем вы думали, - это репозиторий, который мы создали для этого? https://github.com/lucidsoftware/closure-typescript-example

Похоже, это отличная вещь для интерфейса командной строки. Он обертывает Webpack и множество других существующих и новых плагинов. Было бы здорово, если бы CLI мог использовать компилятор Closure под капотом вместо uglifier. В любом случае он абстрагируется от пользователя.

@jjudd да, это лучшее, что у нас есть сейчас, но оно привязано к конкретной (старой) версии ng2 и ее зависимостей, верно?
Нам также нужно объяснить, как использовать externs, чтобы у вас могли быть зависимости, не совместимые с закрытием.

Правда. Мы активно работаем над переходом на последнюю версию Angular прямо сейчас. Надеюсь, это будет сделано очень скоро. Я опубликую обновление, когда мы это сделаем.

@alexeagle: честно говоря, webpack построен на модулях commonjs / amd / es6, поэтому многие функции не работают должным образом (если вообще работают), если модули не в этом формате. некоторые быстрые, которые приходят на ум

• загрузчик URL. Мы импортируем ресурсы в машинописном тексте (или html) как require('./asset.png') и просто выполняя это, веб-пакет обрабатывает копирование, хеширование, сжатие и загрузку изображений там, где это необходимо.
• автоматическое разделение кода (например, с использованием загрузчика маршрутизатора angular2, подобного этому ) и любого другого System.import во всем вашем коде для легкой ленивой загрузки любого контента
• различные другие загрузчики - например, мы используем загрузчик импорта для материала angular2, поскольку материал в настоящее время имеет ссылки на окна для поиска помощников машинописного текста, таких как __extends поэтому мы должны переписать это на global ( пример ). Даже такие вещи действительно работают наиболее элегантно (или менее хакерски) с webpack, когда он обрабатывает вашу сборку так, как он предназначен для
• различные другие плагины - например, плагин html будет создавать наш базовый index.html после запуска полной сборки / пакета, поскольку при этом он знает, какие файлы javascript были созданы (включая их полные пути и хэши) и создает наш корень html шаблон с правильными URL-адресами скриптов с хешами и т. д. соответственно

честно говоря, я реализовывал тот же (или аналогичный) материал много раз с чем угодно, начиная с make / jakefiles, grunt, gulp и т. д., но у меня никогда не было почти такого бесшовного и надежного инструментария сборки, как использование веб-пакета (особенно для количество кода, которое вы должны написать и поддерживать для своей сборки), поэтому я бы хотел увидеть tsickle, позволяющий использовать более распространенные (в мире с открытым исходным кодом) форматы модулей, которые можно интегрировать с такими инструментами, как webpack

tl; dr, webpack просто зависит от использования импорта commonjs, amd или es, и у них есть отличная система загрузчиков и плагинов, которые могут делать много замечательных вещей, если webpack может понимать ваши модули в любом из распространенных javascript форматы, которые, к сожалению, не включают никаких модулей goog.*

lmk, если есть что-то еще, я могу помочь ответить здесь или даже добавить код, который я могу сделать, чтобы попробовать использовать tsickle с другими инструментами, такими как webpack. Я очень хочу, чтобы это продолжалось, насколько это возможно!

и спасибо!

@ steve8708 причина, по которой мы в настоящее время передаем синтаксис goog.module для закрытия компилятора, заключается в том, что в нем есть ошибки / отсутствующие функции для модулей ES6. В прошлый раз, когда я проверял, у них нет поддержки, например, для export * . Команда указала, что они не заинтересованы в поддержке модулей ES6, поскольку они изначально не работают в большинстве браузеров.

Если вам нужно выполнить код TS через эти шаги перед объединением / встряхиванием / минимизацией с помощью компилятора закрытия, нам нужно будет исправить всю поддержку модуля ES6 в компиляторе закрытия. Я не думаю, что сейчас это кому-то принадлежит.

Полезно знать, спасибо @alexeagle

Я только что нашел несколько документов, в которых говорится, что gcc также поддерживает модули commonjs. Я немного протестирую его и выясню, может быть, он более реализован или менее глючит, чем модули es6 в настоящее время.

Если это так, я покопаюсь и посмотрю, возможно ли сделать преобразование модуля goog необязательным в tsickle, и есть ли способ получить преимущества расширенной минификации gcc с аннотациями типа jsdoc, извлеченными из машинописного текста, но с модулями commonjs или es6. Я думаю, что это определенно было бы хорошо для меня и остального сообщества!

Еще раз спасибо за информацию, это очень полезно!

Обсудили еще кое-что здесь лично ... если единственная ошибка компилятора закрытия - это export * , мы могли бы легко сделать опцию tsickle, чтобы сгладить ее в export {symbol1, symbol2, ...} на этапе постобработки. Мы также могли бы добавить аннотации JSDoc (и включить их в наши дистрибутивы ES6).

@alexeagle , было бы

В ходе сегодняшнего тестирования я обнаружил, что tsickle на самом деле уже конвертирует export * в формат export { a, b, c } для модулей es6, так что это отличная новость!

Более того, я клонировал tsickle локально, закомментировал преобразование в модули goog и смог добиться, чтобы tsickle + gcc advanced отлично работал с нашей сборкой webpack, как и надеялся!

Благодаря этому наш основной пакет уменьшился на целых 15%, и при этом в @angular/* еще ничего не аннотировалось. Это выглядит очень захватывающе и многообещающе.

Вдобавок к этому, из исследования, которое я провел сегодня, я вижу, что при переносе с модулями es6 ни один из них не заменяется на goog.require, только вызовы commonjs require. Это действительно хорошая новость, поскольку это означает, что проекты могут использовать tsickle как есть уже сегодня с инструментами, поддерживающими esmodules, такими как rollup и webpack2, при условии, что они заменяют вызовы _all_ commonjs require импортом es6.

К счастью, ts 2.0 значительно упростил эту задачу с помощью declare module '*' , избавив от необходимости использовать require для кода без машинописного текста.

Мне действительно не терпится увидеть, сколько еще мы сможем сэкономить, если в @angular/* es-дистрибутивах будут также аннотации типов от tsickle! Особенно, когда webpack2 все еще не реэкспортирует tree shake, экономия от удаления большого количества связанного, но неиспользуемого кода angular core / common / etc здесь может быть действительно большой!

Решил попробовать и это.

Клонирован последний tsickle , но по-прежнему возникает несколько проблем:

Для меня есть две категории ошибок:
1) export * ошибки компиляции из-за закрытия - та же ошибка, описанная другими выше ...

node_modules/@angular/common/src/location.js:9 (JSC_CANNOT_CONVERT_YET)
ES6 transpilation of ''Wildcard export'' is not yet implemented.
export * from './location/location_strategy';

Будет ли решение опубликовать здесь исходный код Angular без export * ?

2) ключевые слова закрытия в комментариях исходного кода angular, вызывающие ошибки компиляции

node_modules/@angular/core/src/metadata/ng_module.js:15 (JSC_PARSE_ERROR)
Parse error. illegal use of unknown JSDoc tag "stable"; ignoring it
 * <strong i="16">@stable</strong>

Я выполняю сборку, используя накопительный пакет с плагином компилятора закрытия. Я использую rxjs-es вместо rxjs, так как я столкнулся с несколькими проблемами при преобразовании commonJS.

Мне любопытно узнать о плане tsickle vs ngc. Насколько я могу судить, теперь вам нужно запускать их в тандеме ngc -> tsickle . Есть ли планы объединить их, чтобы сократить это до одного шага?

Мне очень интересно посмотреть, как далеко это может зайти. Я предполагаю, что это действительно сводится к структуре кода, но может быть потенциал для огромного сокращения кода. Сделал не угловой POC с закрытием здесь: http://www.syntaxsuccess.com/viewarticle/tree-shaking-in-javascript

Насколько я могу судить, Closure обладает огромным потенциалом в плане оптимизации кода. Мой образец сократил несколько классов до одного лайнера, но до сих пор неясно, насколько хорошо это будет переведено в приложения Angular. Надеюсь!

Теперь, когда PR в ходу, вы можете использовать

    "@angular/common": "angular/common-builds",
    "@angular/compiler": "angular/compiler-builds",
    "@angular/compiler-cli": "angular/compiler-cli-builds",
    "@angular/core": "angular/core-builds",
    "@angular/platform-browser": "angular/platform-browser-builds",
    "@angular/platform-server": "angular/platform-server-builds",
    "@angular/tsc-wrapped": "angular/tsc-wrapped-builds",

и нет export * и весь код имеет JSDoc для закрытия.

@thelgevold @ steve8708 хотите попробовать еще раз?
Я исследую https://github.com/cramforce/splittable с @robwormald

@alexeagle круто !

Я пробую это сейчас, и при использовании версий -builds я получаю эту ошибку от ngc:

Error: Metadata version mismatch for module [path to a project .ts file], found version 1, expected 2

Я не совсем уверен в значении этого сообщения, есть ли у вас какие-либо мысли, как его разрешить?

@tbosch внес изменение после моего. Он обновил сборщик метаданных, и теперь Angular ожидает чтения метаданных версии 2. Однако при обнаружении метаданных версии 1 их следует обновить на месте. Похоже на ошибку, я позволю Тобиасу подтвердить ...

это фиксация: https://github.com/angular/angular/commit/dddbb1c1cb08115f339e34487774c85a3c6493f3

одно дело, есть ли в вашем проекте сгенерированные файлы .metadata.json ? попробовать очистить их и повторить попытку?

@alexeagle Я @angular/core

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

Преобразование таких ссылок, как @angular/core в ../../core/index в коде angular / application, похоже, работает ....

Вот пример ошибки:

node_modules/@angular/common/src/pipes/slice_pipe.js:8: ERROR - required "module$$angular$core" namespace never provided
import { Pipe } from '@angular/core';

Попробовал и свое репо, и, похоже, там тоже происходит то же самое.

Интересно, можно ли что-то добавить к закрытию, чтобы разрешить именованный импорт, например @angular/core на соответствующий физический путь.

@thelgevold Я node_modules/@angular/core/index.js зарегистрировано как module$$angular$core$index . Поскольку семантика ESModule не определена, нет спецификации, говорящей, что «foo / index.js» может быть импортирован с «foo». Поскольку CommonJS позволяет это, rollup и systemjs поддерживают его, но это не указано. Поэтому группа закрытия ответила, что это проблема с загрузчиком модуля, и они не поддерживают это. https://github.com/google/closure-compiler/issues/1710 (а также чат с @MatrixFrog)
Я подозреваю, что изменение import {} from '@angular/core' на from '@angular/core/index' решает эту проблему, хотя это не является полезным обходным путем, поскольку пользовательский код тоже должен это делать.

Я полагаю, что преобразование синтаксиса модуля в commonjs - это еще один подход, хотя добавление инструмента для этого значительно усложняет надежное воспроизведение сборки.

Да, к сожалению, это та же проблема, на которой я сейчас зациклился и не уверен, действительно ли есть простое решение :(

Возможно, нам придется снова отказаться от tsickle, поскольку даже если для нашего собственного импорта мы добавим /index в конец путей, импорт внутри библиотек (например, @angular/platform-browser импорт из @angular/core , etc) также не будет иметь правильных путей для поддержки gcc

Я подумаю об этом больше, но пока похоже, что gcc advanced может быть недоступен для обычного пользователя в ближайшее время, если у кого-то еще нет других идей.

Возможно ли, чтобы ngc выводил JS с длинной рукой для импорта, чтобы защитить пользователя от использования их в своем собственном коде TypeScript.

Тогда как часть выпуска A2 сделать то же самое для кода angular? В основном публикуете версию с полным импортом формы?

Это хорошая идея - внутри у нас есть tsickle convert to goog.module
синтаксис, поэтому мы должны иметь возможность использовать другое преобразование для явного
импорт из /index.js

В среду, 30 ноября 2016 г., в 11:35 Торгейр Хельгевольд [email protected]
написал:

Возможно ли, чтобы ngc выводил JS с длинной нотацией для
import, чтобы защитить пользователя от использования их в собственном коде TypeScript.

Тогда как часть выпуска A2 сделать то же самое для кода angular? По сути
опубликовать версию с полным импортом формы?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/angular/angular/issues/8550#issuecomment-263971981 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAC5Iy255poYsJTn8ZdBAgVZWbagFwzAks5rDdARgaJpZM4IaZIi
.

Ах, отличная идея!

Интересно, может ли это также охватывать не угловые библиотеки? Т.е. выполняет ли tsickle синтаксический анализ модулей без машинописного текста / angular, чтобы он также мог преобразовать import { foo } from 'other-lib' в import { foo } from 'other-lib/index' где это необходимо?

Аналогичным образом, еще один элемент разрешения модуля, который некоторые из основных загрузчиков используют для имитации разрешения модуля узла, если other-lib имеет поле main в их package.json, скажем, указывающее на main.js , сможет ли он (теоретически, если будет реализован) преобразовать импорт из этого пакета в import { foo } from 'other-lib/main' ?

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

Если бы все это было возможно, это было бы совершенно потрясающе и означало бы, что способность использовать tsickle можно было бы вернуть на наш радар, что было бы потрясающе!

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

• Closure скомпилируйте ваш код, Angular и его зависимости (особенно rxjs) в один или несколько пакетов
• предоставить файлы externs закрытия для других библиотек, которые вам нужно взаимодействовать с / из пакета закрытия
• Загрузите другие пакеты библиотеки, используя их миниатюрный js-дистрибутив в отдельном теге скрипта.

Это то, что мы делаем и в Google. Таким образом, не должно быть необходимости запускать tsickle, только ngc.

Ах, понятно, спасибо, что обратили внимание на @alexeagle!

На всякий случай, если повезет, я попросил TS сделать это:
https://github.com/Microsoft/TypeScript/issues/12597
А пока, может быть, мы сможем сделать это без промедления, сейчас я пробую. Вот в чем проблема:
https://github.com/angular/tsickle/issues/288

Обновление: эта проблема с зубами решена. Сборка угловая из этой ветки:
https://github.com/alexeagle/angular/tree/closure
Теперь я создаю дистрибутив ES6 со всеми явными import {} from '@angular/core/index'

Следующая проблема в том, что нам нужен совместимый дистрибутив rxjs. @jayphelps рассматривает историю упаковки rxjs, которая была отложена до версии 5.0.0-final. Тем временем нам, вероятно, все еще понадобится собственный экспериментальный дистрибутив rxjs.

Это действительно отличная работа @alexeagle

Я раздвоил ваш проект и добавил еще несколько «продвинутых» образцов. Хорошая новость заключается в том, что закрывающая часть компилятора действительно прозрачна и совсем не мешает нам.

Я добавил образцы Dynamic Forms (реактивные формы) и Recursive Treeview, и все работает хорошо.

Единственными настройками, которые мне пришлось сделать, были несколько дополнений к конфигурации компилятора закрытия, чтобы получить доступ к директивам форм и ngIF, ngFor и т. Д.

Вилка:
https://github.com/thelgevold/closure-compiler-angular-bundling/tree/add-samples

Я также развернул здесь версию образца:
http://www.syntaxsuccess.com/a2-closure/

Отлично, спасибо, что так быстро подняли это @thelgevold
Для других, наблюдающих за веткой: сегодня я обновил репозиторий примеров, у нас снова есть рабочая установка компилятора закрытия, и теперь нет отдельного скрипта полифиллов. Zone.js встроен в комплект закрытия.

Я думаю, что следующие шаги - попробовать это в некоторых реальных сценариях. Ionic тоже это делает. Затем, где-то в следующем месяце мы постараемся собрать команду Closure Compiler в одной комнате с нами и решить самые большие проблемы с удобством использования. Тем временем @mhevery помогает указать на код, который сохраняется, но его следовало

Вопрос:
Я посмотрел на включение сторонних библиотек при компиляции закрытия.

Проблема с нормализацией путей импорта с использованием компилятора TypeScript заключается в том, что сторонние библиотеки, скорее всего, публикуются только с исходным кодом JS.
Это усложняет нормализацию импорта баррелей без index в конце пути.

Обсуждались ли какие-либо обсуждения об отмене рекомендации в пользу узла moduleResolution ?

Я думаю, было бы не так уж плохо вместо этого использовать классический moduleResolution и всегда включать index в пути импорта.

Я предполагаю, что при компиляции в больших проектах может снизиться производительность. Особенно, если компилятор должен выполнять поиск для каждого импорта, чтобы определить, нужно ли его переписывать, чтобы он был совместим с импортом компилятора закрытия.

При этом компиляция компилятора замыкания (ADVANCED_OPTIMIZATION) изолированно обычно занимает много времени. Может, добавленное время не так уж и заметно?

Мысли?

Я согласен, время компиляции зависит от поиска по индексу, который я добавил в
tsickle - для каждого импорта мы должны снова выполнить moduleResolution.
Внутренне мы конвертируем модули commonJS в goog.module / goog.require - I
представьте, что для нас было бы слишком медленно делать лишний шаг в dev
режим.

Мы можем обсудить вопрос о поддержке разрешения в стиле node_module далее.
На неделе у нас будет день хакатона с командой Closure Compiler.

Тем не менее, даже если компилятор закрытия понял синтаксис модуля для
сторонние библиотеки, типичный код нарушается ADVANCED_OPTIMIZATIONS,
во многом из-за синтаксиса доступа к свойствам (точечный синтаксис переименован, квадрат
скобки синтаксиса нет). Поэтому я думаю, что сторонние библиотеки останутся
вне компиляции закрытия. Внутри мы просто берем их -min.js
distro и объедините его в конец JS, связанного с закрытием.

Мы подумали, что было бы здорово, если бы какой-то файл или пакет могли отказаться
от оптимизации закрытия. Я могу представить себе один практический способ сделать это:
чтобы добавить closureCompilerCompatible: true в package.json библиотек
которые подтвердили совместимость с расширенной оптимизацией закрытия. Затем сборка
инструмент может выбрать библиотеки, которые скомпилированы в пакет, vs.
те, которые решаются с помощью закрывающих externs.

В четверг, 12 января 2017 г., в 18:59 Торгейр Хельгевольд [email protected]
написал:

Вопрос:
Я посмотрел на включение сторонних библиотек при компиляции закрытия.

Проблема в нормализации путей импорта с использованием TypeScript
компилятор заключается в том, что сторонние библиотеки, скорее всего, публикуются только с помощью JS
источник.
Это усложняет нормализацию импорта баррелей без индекса.
в конце пути.

Обсуждались ли какие-либо обсуждения об отмене рекомендации на
пользу node moduleResolution.

Думаю, было бы неплохо вместо этого использовать классический
moduleResolution и всегда включайте индекс в пути импорта.

Я предполагаю, что во время компиляции в
большие проекты. Особенно, если компилятору приходится выполнять поиск для каждого
import, чтобы определить, нужно ли его переписывать, чтобы он был совместим с закрытием
компилятор импортирует.

Тем не менее, компиляция компилятора закрытия (ADVANCED_OPTIMIZATION) в
изоляция обычно занимает много времени. Может быть, добавленное время не
все что заметно?

Мысли?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/angular/angular/issues/8550#issuecomment-272348788 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAC5I49thgsBW1VGc3oyFVvEchxI2D6Zks5rRuivgaJpZM4IaZIi
.

Спасибо за ответ. Мне нравится следить за прогрессом в этом проекте.

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

Мой опыт работы с компилятором закрытия показывает, что он потенциально предлагает невероятные оптимизации, но заставляет вас соблюдать некоторые соглашения. Я все еще рассматриваю его как экспертный инструмент, но мне интересно, есть ли в ngc способы упростить вещи, создав код, соответствующий некоторым из этих соглашений. Externs будет определяться от случая к случаю на основе констант конкретных библиотек, но другим распространенным вариантом использования являются вызовы http.

При работе с http-вызовами ....
На мой взгляд, нам придется заключить «квадратные скобки» в защиту некоторых свойств нашей модели, чтобы компилятор Closure не сокращал имена свойств в ссылках на объект полезной нагрузки. В противном случае сокращенные версии больше не будут соответствовать значениям времени выполнения из фактических полезных данных http.

Я обычно защищаю свойства по мере необходимости, используя квадратную скобку {'firstName': 'Joe'} .
Этот подход хорошо работает для меня, но некоторым людям может не понравиться, что мы должны писать такой код. Может быть, декоратор или что-то подобное может быть подсказкой ngc для генерации JS в этом формате в тех случаях, когда имена свойств должны быть защищены?

Внутри tsickle мы сделали это так
объявить интерфейс User {firstName: string; }
(с помощью "declare") сообщает компилятору Closure, чтобы он не искажал использование
Поле firstName.

Это смутно согласуется с тем, как это уже работает в TS, где "declare"
используется для представления типов вещей, которые находятся за пределами вашего кода TS.

@evmar Отлично! Спасибо, что рассказали мне об этом.

Я обновил свою вилку, чтобы использовать новую сборку моментальных снимков из репозитория angular. https://github.com/thelgevold/closure-compiler-angular-bundling

Насколько мне известно, единственная нестандартная зависимость на данный момент - это кастомная сборка rxjs.

Чтобы опробовать более реалистичные сценарии, я начал переносить свои демонстрационные компоненты на закрывающую вилку компилятора.

Вот две сборки, если вас интересует сравнение между стандартной сборкой накопительного пакета и сборкой закрывающего компилятора моих компонентов:

http://www.syntaxsuccess.com/closure-compiler-demo
http://www.syntaxsuccess.com/rollup-compare-demo

Я не знаю навыков css, поэтому в демо-версии серьезно не хватает стиля, но интересно сравнить две сборки по размеру:

Вот статистика размеров:
Накопительный пакет: 130 КБ
Закрытие: 79,2k

В сборке Closure вы также можете пропустить прокладку core-js, если ваш браузер поддерживает es6 (Chrome, Edge и т. Д.). Для сборки Rollup требуется прокладка, независимо от поддержки es6 в браузере. Это побочный эффект того, что декораторы не встряхивают.

Со временем я буду расширять эту демонстрацию. В настоящее время он использует маршрутизатор, формы и ReactiveForms.

До сих пор было относительно просто кодировать компилятор замыкания. Единственный раз, когда мне пришлось внести специальные изменения, чтобы заставить его работать, была демонстрация «сортируемой сетки». Сетка выполняет динамический поиск по имени столбца, что несовместимо с изменением имен свойств.

Как обсуждалось ранее, можно предотвратить искажение свойств, используя интерфейс с declare
бывший:

export declare interface Person {
  firstName: string;
  lastName: string;
  age: number;
}

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

Вот статистика размеров:
Накопительный пакет: 130 КБ
Закрытие: 79,2k

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

В моем случае разница между Angular и Application code / rxjs составляет примерно 70/30.

Вот вид проводника исходной карты в комплекте: http://www.syntaxsuccess.com/closure-compiler-demo-map

@ b-strauss Миско считает, что примерно половина веса Angular должна избавиться от дерева, но Closure не понимает, что некоторые из наших шаблонов кодирования не имеют побочных эффектов, поэтому мы упускаем несколько оптимизаций. Ожидайте, что число закрытия со временем снизится примерно на 20 тысяч по сравнению с альтернативами.

@thelgevold технически Angular должен зависеть только от обещаний и коллекций ES6 (возможно, повторяемых, но я думаю, что это необязательно), а не от всех es6-shim. https://github.com/angular/angular/blob/master/modules/tsconfig.json#L22

@thelgevold: да, мы должны подключить
https://github.com/angular/angular/issues/14325

@alexeagle Было бы более оптимизировано, чтобы как-то преобразовать в квадратную скобку, эквивалентную для этих случаев?

Не уверен, что это сработает, но я понимаю, что externs должен быть ограничен ссылками на внешние фреймворки, такие как глобальные переменные, «принадлежащие» другим фреймворкам.

Я думаю, что Closure может лучше справиться с оптимизацией цитируемых свойств за счет комбинации одной полной ссылки и сокращенных внутренних ссылок на одно и то же свойство.

Я считаю, что externs менее оптимизированы, поскольку не затрагивают никаких ссылок на имя свойства. Это означает, что 50 ссылок на firstName останутся как firstName, в то время как квадратные скобки могут оставить одну общедоступную ссылку как firstName и исказить остальные 49 внутренних ссылок.

@thelgevold это правда, подход externs помечает это имя свойства как не подлежащее переименованию везде.
У нас нет никакого способа автоматически переписать точечный доступ в цитируемый доступ, хотя я полагаю, что с системой типов мы могли бы видеть declare interface и знать, когда это делать.

Но после сжатия это может не иметь значения? Если firstName входит в словарь в заголовке сжатого файла, это может не иметь большого значения, сколько раз на него ссылаются в коде.

FWIW - это тот подход, который мы используем сейчас внутри компании Google. Но я думаю, что мы должны поэкспериментировать с вашим предложением, если у нас будет время.

Я почти уверен, что закрытие никоим образом не оптимизирует цитируемые свойства. Замыкание просто удаляет квадратную скобку из этого: model['firstname'] в это x.firstname .

AFAIK «чистый» способ с внешними файлами и квадратной нотацией дает тот же результат.

проблема в том, что notModel.firstName также будет y.firstname вместо y.z

Замыкание должно иметь возможность номинально различать типы этих экземпляров по типам, указанным в externs. Так это работало в старом «глобальном» мире. Я понятия не имею, как сгенерировать externs для классов с одинаковыми именами, но из разных модулей.

@alexeagle Вы, наверное, правы. После gzip пользы от gzip не будет.

Вероятно, это также будет сложно, поскольку вам, скорее всего, придется обнаружить все «одинаковые» ссылки firstName и полностью переписать их на ['firstName']. В противном случае будет смесь нотации .firstName и ['firstName'] , которая сломается во время выполнения.

@ b-strauss Замыкание преобразует ['firstName'] в .firstName. Однако вот теория оптимизации, лежащая в основе [''] и externs: https://developers.google.com/closure/compiler/docs/api-tutorial3
Я наблюдал такое поведение в некоторых своих экспериментах, но, возможно, здесь оно не стоит усилий.

Для мобильных устройств более крупный исходный файл JS все равно займет больше времени для синтаксического анализа. Дело не только в размере поста в формате gzip.

@thelgevold Я знаю, что за этим стоит. :)

Я просто написал небольшой тест:

Этот код приложения:

/**
 * <strong i="9">@constructor</strong>
 */
function NotMyModel() {
  this.firstname = 'foo';
}

console.log(new NotMyModel().firstname);
console.log(new MyModel().firstname);

вместе со сторонним кодом:

<script>
  function MyModel() {
    this.firstname = 'foo';
  }
</script>

и эти внешние:

/**
 * <strong i="16">@constructor</strong>
 */
function MyModel() {
}

/**
 * <strong i="17">@type</strong> {string|null}
 */
MyModel.prototype.firstname;

производит следующий вывод:

(function () {
  console.log("foo");
  console.log((new MyModel).firstname);
})();

Closure может различать два имени на основе номинальных типов и даже вставляет первое. Как я уже сказал, в старом «глобальном» мире это не было проблемой, потому что лучше всего было всегда добавлять префиксы к вашим типам com.bstrauss.MyClass .

Вопрос в том, как tsickle должен генерировать экстерны в мире, где типы из двух разных модулей могут иметь одно и то же имя?

AFAIK нет эквивалента goog.module для externs.

@ b-strauss Спасибо, что поделились этим экспериментом.

Мой первоначальный комментарий был больше о том, как [''] может оптимизировать несколько ссылок на одно и то же свойство MyModel.firstName . Не столько об оптимизации для кроссовера с одинаковыми именами для разных объектов модели.

Насколько я понимаю, если у вас есть 10 MyModel().firstname refs в вашем коде, использование [''] потенциально может позволить Closure создать внутренний псевдоним короткой версии. Таким образом, чистый размер меньше, поскольку он сохраняет firstName там, где его ожидает другой код, но выигрывает от более короткого имени для частных / локальных ссылок. Насколько я понимаю, внешний вид не принесет вам такой выгоды, поскольку он оставляет все ссылки в покое.

@ b-strauss мой план состоял в том, чтобы решить эту проблему на https://github.com/angular/tsickle/issues/352 , изменив имя externs и затем применив псевдонимы локально. То есть для файла foo/bar/baz.ts :

/** <strong i="8">@externs</strong> */
function tsickle_from_foo_bar_baz_ts_MyModel() {}
/** <strong i="9">@type</strong> {string} */
tsickle_from_foo_bar_baz_ts_MyModel.prototype.firstName;

И на сайте использования:

goog.module('foo.bar.baz');

// Alias:
var MyModel = tsickle_from_foo_bar_baz_ts_MyModel;

// ... later on ...
new MyModel().firstName;

Давайте перейдем к обсуждению этого вопроса, эта ветка становится немного несфокусированной.

Некоторое время назад в этой теме упоминается обсуждение того, насколько хорошо может быть принята цепочка сборки на основе Closure Compiler сообществом. Даже если он останется второстепенным в числовом отношении к стеку Webpack в Angular-CLI, я подозреваю, что он все равно получит достойное распространение, если будет обеспечивать меньший результат. Размер по-прежнему имеет большое значение, особенно на мобильных устройствах.

@alexeagle re "сторонние библиотеки должны будут оставаться за пределами компиляции закрытия" - это, вероятно, хорошая отправная точка, но если все наладится, когда Closure можно почти тривиально использовать в коде приложения Angular, я считаю, что это создаст значительное давление на Создатели надстроек для Angular (хотя, возможно, и не более широкая экосистема) проверяют, работают ли их материалы с Closure. То же самое происходило в последние несколько месяцев в отношении AOT, в начале осени большинство дополнительных библиотек сказали "AOT?" но сегодня большинство из них, с которыми я сталкиваюсь, работают с AOT или хорошо осведомлены и движутся в этом направлении.

Если кто-то следил за этой работой в различных репозиториях, связанных с этим выпуском, в течение последнего года, я думаю, что последние из них, которые я видел выше, по-прежнему указывают на пакеты «-builds», которые были необходимы до недавнего времени. Но теперь Angular 4 rc поставляется с модулями ES2015, так что в этом больше нет необходимости. Вот ветка, которую я обновил, чтобы работать с последней, в процессе понимания того, что происходит с использованием Closure.

https://github.com/kylecordes/closure-compiler-angular-bundling/tree/update-versions

Такое ощущение, что мы находимся на пороге производственной цепочки сборки Angular, состоящей только из ngc (с tsc внутри) и Closure. Это хороший короткий стек.

Я опубликовал следующий репозиторий, показывающий, как использовать 4rc.2, ngc (AOT), Closure Compiler:

https://github.com/OasisDigital/angular-aot-closure

Технологически это мало что может предложить Алексу, но у него другая цель. Я пытаюсь сделать этот репозиторий множеством комментариев и текста, объясняющего, как и почему. Поэтому, пожалуйста, не стесняйтесь открывать вопрос по нему, если что-то недостаточно объяснено в комментариях или README.

@nosachamos Дикая догадка: что-то в цепочке инструментов (возможно, tsickle или Closure?) не ожидало параметра с именем this . Мое предложение:

• Отредактируйте свою локальную копию источника RxJS, измените имя этого параметра, подтвердите исправление. Если так, то ...
• Задайте вопрос (или даже PR) RxJS, чтобы переименовать этот this и любые аналогичные параметры this . Надеюсь, команда RxJS увидит достоинства такого изменения; возможно, доброе слово от команды Angular ( @alexeagle ?) По такой проблеме поможет.
• Поместите проблему с простым повторным случаем для Closure, о параметре с именем this ... и он не воспроизводится там, посмотрите в другом месте в цепочке инструментов (tsickle?).

@kylecordes Ops, я обнаружил свою проблему и удалил комментарий, когда вы печатали.

Для протокола, моя проблема заключалась в том, что аргумент с именем «this» удалялся во время транспиляции.

Оказывается, замыкание вызывало эту функцию с использованием call , поэтому this был фактически установлен таким образом и не нуждался в передаче. Если я переименую "this" в "this2", аргумент будет хранится. Думаю, транспиллер умнее, чем я думал.

Моя проблема заключалась в эффектах ngrx, а не в rxjs. Ngrx / effects обращается к эффектам через их имена, используя нотацию скобок, которая нарушается компилятором замыкания, когда он переименовывает все объекты. Чтобы предотвратить эту проблему, в конструкторе классов, содержащих ваши эффекты, присвойте их имена «this», используя скобки:

export class MyEffects {

  @Effect()
  doSomething$: Observable<Action> = this.actions$ ...

  constructor() {
    this['doSomething$'] = this.doSomething$;
  }

}

Итак, я почти приступил к работе над реальным приложением, использующим стек ngrx. Я пишу то, что считаю последним ручным экстерном, необходимым в моем случае. Если все работает хорошо, я создам ветку для примера приложения здесь со стеком ngrx в качестве демонстрации. Я использую свою собственную вилку ngrx / core и ngrx / store, в то время как мои PR для расширения экспорта подстановочных знаков не объединяются, но, кроме этого, я думаю, что это будет хорошо.

Я буду держать вас в курсе, ребята.

Можете ли вы сообщить об ошибке против tsickle с дополнительной информацией по проблеме this ? Мы хотим, чтобы вам не нужно было вручную переименовывать такие переменные.

Можно ли исправить ngrx, чтобы не использовать скобки?

@nosachamos на основе вашего удаленного комментария и моего комментария, который, возможно, следует удалить, есть ли какие-либо проблемы, о которых следует сообщить? (за @evmar )

@kylecordes Может быть,
но я думаю, что это происходит, так это то, что транспилятор может выяснить, что функция имеет "this", установленное вызовом call . Таким образом, в этом случае он может безопасно удалить аргумент, поскольку this будет тем, что передано в call . Это было бы неверно, если бы аргумент был переименован, поэтому он сохраняет аргумент. Я думаю, что в «этом» частном случае транспиллер в порядке. Фактически, переименование аргумента не решает проблемы, поскольку реальная проблема заключалась в доступе к скобкам.

@evmar Я так считаю. Этот доступ к скобкам занимает центральное место в их работе, но я подозреваю, что аннотирование базового словаря с @dict закрытия будет достаточно, чтобы решить проблему. Я попробую и отправлю им PR, если это сработает. В противном случае я отправлю PR в их README с примечанием об обходном пути при использовании ngrx / effects с закрытием.

Обратите внимание, что любая аннотация типа Closure, добавленная в код TS, удаляется Tsickle, поэтому добавление @dict туда не поможет.

Моя проблема заключалась в эффектах ngrx, а не в rxjs. Ngrx / effects обращается к эффектам через их имена, используя нотацию скобок, которая нарушается компилятором замыкания, когда он переименовывает все объекты. Чтобы предотвратить эту проблему, в конструкторе классов, содержащих ваши эффекты, присвойте их имена «this», используя скобки:

@nosachamos Не @Input() и @Output() ? Другой вопрос: должно ли закрытие переименовывать оформленные поля?

@evmar Я транслирую с помощью removeComments: false и все мои аннотации к закрытию передаются в код ES6, который я скармливаю закрытию, так что все должно быть хорошо. Я использую @dict в других местах, и это нормально.

@awerlang нет, @dict - это аннотация в стиле jsdoc, а не настоящая аннотация, такая как @Input. Эти аннотации закрытия переходят в комментарии.

@nosachamos наш тестовый пример - это ввод https://github.com/angular/tsickle/blob/master/test_files/jsdoc/jsdoc.ts, производящий этот вывод
https://github.com/angular/tsickle/blob/master/test_files/jsdoc/jsdoc.js
где вы увидите, мы меняем большинство аннотаций. Может, есть ошибка.

@evmar о, я компилирую с ngc и использую

    "target": "es6",
    "module": "es2015",

а также

  "angularCompilerOptions": {
    "skipMetadataEmit": true,
    "annotationsAs": "static fields",
    "annotateForClosureCompiler": true
  },

Так что я получаю только ES6, без goog.modules ... так что вроде все работает как задумано, и я получаю аннотации закрытия. Это для RxJ. Для пакетов, которые взаимодействуют с angular (компоненты, модули и т. Д.), skipMetadataEmit устанавливается в false .

@nosachamos, насколько я понимаю, tsickle step не может этого сделать и не будет делать своего при запуске через ngc , если только вы не используете "module": "common" . Tsickle применяет это ограничение при запуске с помощью собственного интерфейса командной строки, получает ли он возможность работать с выводом модуля es2015 при запуске через ngc ? Вы видите JSDoc, сгенерированный tsickle, в выходных данных модуля es2015?

@kylecordes да, я получаю тот же результат, что и в демонстрационном репозитории, который вы опубликовали выше, при компиляции с помощью tsc-wrapped и rxjs-tsickle tsconfig.

можем ли мы переместить ошибки в другой выпуск? он не масштабируется для решения отдельных проблем с отслеживанием. Спасибо!

@alexeagle абсолютно. Сначала я разместил здесь, потому что думал, что это актуально (проблема в том, как rxjs объявлял аргументы с именем "this", которые терялись). Доделать нечего, но если что-то появится, мы сделаем отдельный выпуск.

@nosachamos Действительно ... Я только что обнаружил, что tsickle-via-ngc или -cli-wrapped действительно могут обрабатывать module:es2015 .

@alexeagle А, ой. При более чем 90 комментариях я не понял, что это проблема с отслеживанием. Будет делать новые вопросы, если они возникнут.

Еще раз взглянул на сгенерированный пакет. Заметил, что здесь определенно есть место для дальнейшего сокращения кода.

Closure не всегда легко идентифицировать ненужный код, поскольку из-за существующей структуры кода иногда кажется, что код нужен.

Основываясь на приложении POC в репозитории @alexeagle , я выбрал несколько излишне включенных элементов и сделал несколько временных настроек в источнике, чтобы вытеснить их из пакета.

Похоже, здесь есть несколько повторяющихся паттернов:

Класс службы может не понадобиться приложению, но если служба будет добавлена ​​в массив поставщика по пути, это может привести к тому, что класс включит ее в пакет. Примеры: AnimationDriver и AnimationQueue . Удалив ссылки поставщиков на эти классы, я могу получить эти классы из пакета.

Пример приложения в репозитории Alex не выполняет никаких запросов QueryList, но большая часть кода, связанного с Query, все еще находится в пакете.
В этом случае Closure не может исключить код, потому что код находится в операторе switch, где обрабатываются несколько сценариев.
Взгляните на createViewNodes в core.js и, в частности, на предложение NodeType.Query .

case NodeType.Query:
       nodeData = (createQuery());
       break;

Условия в этом методе разрешаются во время выполнения, поэтому Closure должен включать весь код, чтобы удовлетворить все условия в переключателе. Я удалил это конкретное предложение, и код был исключен из пакета.

Это всего лишь два простых примера, но если вы продолжите идти по этому пути, это приведет к заметному уменьшению размера. Я не очень далеко продвинулся с этим образцом, но я, вероятно, удалил примерно 1 КБ, рассмотрев 4-5 подобных случаев.

Я также провел второй эксперимент, в котором вручную удалил кучу кода (без использования Closure). Я опустил мое приложение до 16,6 КБ, и я считаю, что еще есть место для удаления. Вот образец: http://www.syntaxsuccess.com/viewarticle/minimal-angular-application . Этот конкретный эксперимент является серьезным взломом, но, по крайней мере, он доказывает, что вы можете запустить приложение Angular с очень небольшим кодом.

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

Просто подумайте вслух, но теоретически компилятор ngc не может сгенерировать код для таких вещей, как createViewNodes исходя из потребностей конкретных приложений. Таким образом, если вашему приложению не нужны Pipes, QueryList или что-то еще, эти конкретные операторы case будут исключены из сгенерированного кода.

Мысли?

Основываясь на том, что я узнал при удалении кода в пакетах вручную, я применил аналогичные изменения к пакетам в закрывающей вилке.

Я положил твики в ветку на случай, если вам интересны результаты: https://github.com/thelgevold/closure-compiler-angular-bundling-old/tree/tweaking-src

Вот разница между исходными и измененными пакетами: https://github.com/thelgevold/closure-compiler-angular-bundling-old/commit/d1b3954e7e8a5b2dbb193683f9a3057322870d60

Если вы хотите попробовать, просто замените пакеты по умолчанию на модифицированные. Я использую Angular 4.0.0 для этого эксперимента.

Вот цифры с новыми комплектами:

Новый размер теперь составляет ~ 15 КБ в сжатом виде и немного меньше с использованием brotli.

++ ls -alH dist/bundle.js dist/bundle.js.brotli dist/bundle.js.gz dist/bundle.js.map
-rw-r--r--  1 tor  staff   47487 Mar 26 13:58 dist/bundle.js
-rw-r--r--  1 tor  staff   13979 Mar 26 13:58 dist/bundle.js.brotli
-rw-r--r--  1 tor  staff   15482 Mar 26 13:58 dist/bundle.js.gz
-rw-r--r--  1 tor  staff  133888 Mar 26 13:58 dist/bundle.js.map
++ for script in dist/bundle.js node_modules/zone.js/dist/zone.min.js
++ gzip --keep -f node_modules/zone.js/dist/zone.min.js
++ bro --force --quality 10 --input node_modules/zone.js/dist/zone.min.js --output node_modules/zone.js/dist/zone.min.js.brotli
++ ls -alH node_modules/zone.js/dist/zone.min.js node_modules/zone.js/dist/zone.min.js.brotli node_modules/zone.js/dist/zone.min.js.gz
-rw-r--r--  1 tor  staff  29634 Mar 25 11:00 node_modules/zone.js/dist/zone.min.js
-rw-------  1 tor  staff   8759 Mar 26 13:58 node_modules/zone.js/dist/zone.min.js.brotli
-rw-r--r--  1 tor  staff   9516 Mar 25 11:00 node_modules/zone.js/dist/zone.min.js.gz

Очевидно, что это сложно воспроизвести без реструктуризации исходного кода Angular, но, по крайней мере, интересно посмотреть, насколько маленьким может стать базовое приложение.

Не уверен, насколько это полезно, но это, по крайней мере, забавный эксперимент :-)

В итоге:
Большая часть экономии достигается за счет удаления кода из структур switch / if-else. Замыкание в настоящее время не может сделать вывод, что некоторые параметры недоступны во время выполнения для данного приложения. Другой случай - массивы провайдеров, заполненные неиспользуемыми сервисами.

Как я понимаю из работы @thelgevold , наблюдается значительное уменьшение размера вывода с относительно незначительной или умеренной корректировкой для Angular:

• Добавьте меньше функций с помощью if и включите исходный код.
• Снова предварительно настроенный доступ к меньшему количеству этих функций во встроенных массивах поставщиков.
• Настройте компилятор (влияющий как на JIT, так и на AOT), чтобы сгенерировать дополнительные биты кода для подключения этих функций / поставщиков в сгенерированный код ... если функции действительно используются.

Мне интересно, что кто-то из основной команды думает об этом, действительно ли это от незначительного до умеренного и есть ли интерес в том, чтобы пойти по этому пути.

Сегодня у нас есть выпуск rxjs, который работает с компилятором закрытия, и я обновил репозиторий примеров.
https://github.com/alexeagle/closure-compiler-angular-bundling

Внешние файлы также очищены - Angular и Zone.js распределяют необходимые внешние модули в своих соответствующих пакетах.
Вскоре мы добавим некоторую документацию и объявление о поддержке.

Теперь, когда все это устранено, на данный момент у вас есть представление о том, как это в конечном итоге будет интегрировано с остальной частью существующего инструментария?

например, может ли в конечном итоге быть добавлена ​​опция в @ ngtools / webpack для автоматического запуска вывода AOT через Closure (и / или некоторые задокументированные шаги конфигурации для webpack-closure-compiler)? Или это что-то, что обязательно должно заменить веб-пакет?

Можно ли реализовать ngx-bootstrap с закрытием?

https://github.com/valor-software/ngx-bootstrap

Хотел предоставить обновление:

У нас есть репозиторий примеров и бета-редактор Lucidchart, работающий с расширенной оптимизацией. Мы провели небольшой тест, используя нашу версию с простой оптимизацией, и наша версия с расширенной оптимизацией выйдет сегодня или завтра.

Версия Angular, используемая в репозитории примера, была обновлена ​​до RC5 (HEAD по состоянию на вторник, 16 августа).

Репозиторий примера и сопровождающий его контейнер Docker были обновлены на случай, если кто-то захочет попробовать его. Вот ссылка на пример репозитория https://github.com/lucidsoftware/closure-typescript-example

Размеры связки

Окончательный размер пакета для примера проекта, использующего расширенную компиляцию, указан ниже. Примечание: пример репо включает код, идущий от js -> ts с использованием clutz, а затем ts -> js с использованием tsickle. Это немного больше, чем просто приложение Hello World.

Uncompressed: 112K
Brotli quality 10: 29K
Gzip: 34K

Заметки о том, как заставить это работать

Вот заметки о том, что потребовалось для работы расширенной оптимизации. Если я что-то забыл, я собираюсь предоставить ссылки на все наши форки, в которых есть все наши коммиты.

Пример репо

Файлы Externs для Zone, Reflect и Jasmine были включены в процесс сборки, поэтому эти вызовы функций не были переименованы.

Чтобы обойти ошибку компилятора Closure, когда статические методы теряются, у нас есть действительно хакерская команда sed, которую мы запускаем для встроенных файлов Angular js, заменяя все строки, которые включают ключевое слово static, строкой, которой предшествует / ** @nocollapse * / . Вот ссылка на ошибку закрытия: google / closure-compiler # 1776

Угловой

Самое большое изменение, которое мы внесли в Angular, - это использование аннотированного вывода Tsickle во время компиляции. Мы думали, что сделали это в прошлый раз, но у нас была ошибка, из-за которой аннотированный вывод выбрасывался: D

Было несколько мест, где Angular называет функции строками. Эти функции упоминались в других местах с использованием точечной нотации. Соответственно, одни ссылки были переименованы, а другие нет. Мы изменили Angular, чтобы везде использовать точечную нотацию для этих функций, чтобы они всегда переименовывались.

Мы также обновили Angular / Tsickle, чтобы не комментировать файлы .d.ts.

Мы заставили Angular хорошо работать с ES6, поэтому он работает в некомпилированном режиме. Мы изменим некоторые места, где .apply использовался в конструкторе, чтобы использовать ключевое слово new.

Цикле

Мы исправили ошибку в tsickle, из-за которой интерфейс командной строки не всегда включал все исходные файлы во время аннотации. Список имен файлов из программы TypeScript должен был использоваться, вместо этого мы использовали другой список имен файлов.

Ссылки на все наши форки проектов, чтобы эта работа работала

Угловой: https://github.com/lucidsoftware/angular/tree/closure-bundle
Цикле: https://github.com/lucidsoftware/tsickle/tree/closure-bundle
RxJS: https://github.com/lucidsoftware/rxjs/tree/closure-hack
наблюдаемый символ: https://github.com/lucidsoftware/symbol-observable/tree/closure
Clutz: https://github.com/lucidsoftware/clutz

Мы воспроизвели работу @alexeagle и более свежую версию Angular. Весь процесс сборки является автоматическим, поэтому вы можете отслеживать все, от источника до конечного результата. Вы можете увидеть это в действии на https://github.com/lucidsoftware/closure-typescript-example. Инструкции по запуску примера можно найти в README для репозитория примера. Для проекта существует контейнер Docker, поэтому его может попробовать практически любой желающий.

В приведенном выше примере используются Angular 2, clutz и tsickle. Closure JS используется в Angular 2 TS, который скомпилирован в JS, совместимый с Closure.

Изменения, которые мы внесли в зависимости, чтобы заставить это работать, во многом такие же, как у Алекса. Мы добавили несколько изменений и несколько изменений, которые больше не нужны. Тем не менее, основная идея остается той же. Мы используем модифицированный ngc или tsickle в Angular 2 и его зависимостях для создания версий этих зависимостей, совместимых с Closure.

Компилятор закрытия

Строить из головы больше не нужно. Просто используйте одну из версий с июня или июля.

Угловой

https://github.com/lucidsoftware/angular/tree/closure-bundle

Основная часть работы в исходном коде Angular 2 заключается в изменении ngc для создания компилируемых js в Closure путем добавления нескольких шагов tsickle в tsc-wrapped. Есть несколько приемов, через которые мы перескакиваем, чтобы использовать измененный источник в качестве входных данных для компилятора TypeScript в одном из проходов tsickle. В противном случае это довольно просто.

Мы также изменяем определенные модули Angular, чтобы они были скомпилированы в JS, совместимый с Closure, помещая блок angularCompilerOptions в tsconfig.json, например, так

"angularCompilerOptions": {
  "googleClosureOutput": true
}

Затем, когда вы запустите build.sh эти модули получат желаемый результат.

Файл тестовой утилиты, использующий selenium-webdriver, изменен, потому что selenium-webdriver отсутствует, и мы не хотели делать его совместимым с закрытием.

RxJS

https://github.com/lucidsoftware/rxjs/tree/closure-hack

Процесс сборки RxJS изменен для сборки с помощью Makefile из нашего проекта. Примерно половина процесса сборки выполняется в JS, а другая половина - в Make. Это довольно неприятно.

Единственные другие изменения, помимо цели сборки, - это несколько мелких вещей, которые заставят RxJS скомпилировать с TypeScript и Closure.

символ-наблюдаемый (зависимость RxJS)

https://github.com/lucidsoftware/symbol-observable/tree/closure

RxJS теперь зависит от некоторого кода, который раньше был частью исходного кода RxJS, а теперь является его собственным модулем. Мы модифицируем этот модуль (который является JS), чтобы он был совместим с компилятором Closure. Файлов всего два, так что я сделал это вручную.

серп

https://github.com/lucidsoftware/tsickle/tree/ignore-type-comments

Мы модифицируем Tsickle двумя способами:

1. Добавьте параметр --ignoreTypesInComments. Это предотвращает появление ошибки tsickle при обнаружении jsdoc в комментариях. Это необходимо для компиляции RxJS, который имеет кучу комментариев jsdoc.
2. Измените pathToModuleName чтобы CLI был таким же, как pathToModuleName мы используем в ngc. Таким образом, модули будут называться одинаково при запуске через tsickle или ngc. Это должно быть зафиксировано в восходящем направлении, потому что текущий pathToModuleName иногда дает недопустимые имена goog.module.

привет, я установил ваш проект, но при выполнении команды "make run" появляется ошибка:
'tools/@angular/tsc-wrapped/src/compiler_host.ts (55,32): ошибка TS2345: аргумент типа ts.Program не может быть назначен параметру типа ts.Program'. '
Не могли бы вы помочь мне?

Эта проблема была автоматически заблокирована из-за бездействия.
Сообщите о новой проблеме, если вы столкнулись с аналогичной или связанной проблемой.

Узнайте больше о нашей политике автоматической блокировки разговоров .

_{_Это действие было выполнено автоматически ботом. _}