Angular: استخدم Closure Compiler مع مترجم قالب غير متصل بالإنترنت

الجزء الذي أعتقد أنني في أشد الحاجة إلى إرشادك بشأنه هو مكان / كيف يتناسب هذا مع عملية البناء الزاوي الأكبر.
هل نريد (1) بناء الزاوي نفسه كحزمة خارجية مصغرة؟ أو (2) تجميع الكود الزاوي + المستخدم معًا في حزمة واحدة؟ في الحالة الأخيرة ، سنحتاج إلى الاندماج في gulp أو أي شيء آخر.

نقوم بتوزيع الحزم الزاويّة ، مثل ES5 مع محمل وحدة UMD مدمج.
ومع ذلك ، سيكون من المستحيل فصل هذا مرة أخرى عن بعضه البعض لزعزعة الشجرة
لذلك كانت خطتنا رقم 2.
لست متأكدًا من أننا يجب أن نلتزم ببناء مكونات إضافية للعديد من الشعبية
أدوات بناء userland ؛ سيختارها الآخرون في المجتمع. أعتقد أن أ
أبسط "npm run build && npm run close-compiler" مع البرامج النصية shell
يكفي في هذه المرحلة.

يوم الاثنين 9 مايو 2016 الساعة 11:26 صباحًا Evan Martin [email protected]
كتب:

الجزء الذي أعتقد أنني في أشد الحاجة إلى توجيهاتك بشأنه هو مكان / كيف يتناسب هذا
عملية البناء الزاوي الأكبر.
هل نريد (1) بناء الزاوي نفسه كحزمة خارجية مصغرة؟ أو
(2) تجميع الكود الزاوي + المستخدم معًا في حزمة واحدة؟ في الأخير
الحالة سنحتاج إلى الاندماج في gulp أو أي شيء آخر.

-
أنت تتلقى هذا لأنك قمت بتأليف الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/angular/angular/issues/8550#issuecomment -217947352

لمعلوماتك jeffbcross ، ربما يمكن لهذا أن يجعل عرض PWA الخاص بك لـ I / O

نعم ، سيكون ذلك رائعًا إذا تمكنا من تشغيل هذا بحلول نهاية هذا الأسبوع.

بعض الملاحظات من الاختراقات التي كان عليّ تقديمها حتى الآن ، على أمل أن يتمكن الآخرون من إعادة إنتاجها:

لا يتعامل مترجم الإغلاق مع كل بناء جملة الوحدة النمطية ES6 ، ولا يشجع على استخدامه. لذلك كانت استراتيجيتنا حتى الآن هي استخدام بناء جملة goog.module . هذا ليس خيار --module لـ tsc ، لذلك نستخدم tsickle لإعادة كتابته. هذا يعني أن الزاوية وتبعياتها يجب أن تنبعث باسم "Closure ES6".

تحتاج إلى إنشاء مترجم إغلاق من HEAD ، راجع https://github.com/google/closure-compiler/blob/master/README.md#building -it-yourself

لإنشاء زاوية في الإغلاق ES6 ، لديّ تعديلات محلية في أداة ngc لتشغيل تعليق توضيحي لإغلاق tsickle و convertCommonJsToGoogModule. انظر https://github.com/alexeagle/angular/tree/closure_hack2
أنشئ الزاوي بالطريقة المعتادة باستخدام ./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 ، قمت بالفعل بتثبيت مترجم الإغلاق المدمج محليًا ، وحزم 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 خيارًا واحدًا فقط لبرنامج
اهتزاز الشجرة / الحزمة / Es6-to-5 / تصغير خط الأنابيب. إذا اخترت الإغلاق
خيار المترجم ، يمكنك استخدام تبعية 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.

التغييرات التي أجريناها على التبعيات لجعل هذا يعمل إلى حد كبير هي نفسها تغييرات Alex. هناك بعض التغييرات التي أضفناها وبعض التغييرات التي لم تعد ضرورية. بغض النظر ، الفكرة الأساسية هي نفسها. نستخدم صيغة ngc أو tsickle معدلة على Angular 2 وتبعياتها لإنتاج إصدارات متوافقة مع Closure لتلك التبعيات.

مترجم الإغلاق

لم يعد البناء من الرأس ضروريا. ما عليك سوى استخدام أحد الإصدارات من يونيو أو يوليو.

الزاوي

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

الجزء الأكبر من العمل في Angular 2 source هو تعديل ngc لإنتاج Closure compilable js عن طريق إضافة بضع خطوات tsickle إلى tsc-ملفوفة. هناك عدد قليل من الأطواق التي ننتقل إليها من أجل استخدام المصدر المعدل كمدخل إلى مترجم 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 غير صالحة.

• قم بتشغيل أداة هزاز الشجرة لإزالة وحدات ES6 التي لا يمكن الوصول إليها من نقطة الدخول ، في العرض التوضيحي الخاص بنا ، أظهرنا تجميعًا
• تشغيل حزمة لتقليل واردات الوحدة النمطية إلى إعلانات في ملف واحد ؛ أظهرنا system.js
• خفض المستوى إلى ES5 - أظهرنا ذلك باستخدام TypeScript
• تصغير لتقصير أسماء الرموز ، استخدمنا uglify.

في حين أنه ربما لا يمكن أن يتطابق مع حجم الإخراج النهائي لمجمع Closure Compiler ، فإن حزمة الويب 2 (باستخدام أداة التحميل المطبوعة ومكونات التحسين القياسية) تحصل على كل هذه الخطوات.

أود أن أزعم أن فائدة المطورين الذين يستخدمون بالفعل (أجرؤ على القول _تطلب_) أداة مثل حزمة الويب في مكدسهم ، وبالتالي عدم الحاجة إلى إضافة المزيد من التبعيات (المخترقة) ، هو أكثر أهمية من تقليل وحدات البايت الإضافية في الحمولة النهائية.

أحب أن أسمع أفكارك!

jjudd شكرًا جزيلاً لك على نشر الريبو الخاص بك وهذه الملاحظات ، فهذا مفيد حقًا.

هل لديك حجم تطبيق مصغر يمكنك مشاركته؟ ربما باستخدام ضغط Brotli لذلك لدينا مقارنة من التفاح إلى التفاح مع مثال hello world close-ng2 (الذي كان 26.2 كيلو)

JamesHenry نحن نتفق على أن webpack 2 هو الطريق إلى الأمام لمعظم المطورين. برنامج Closure compiler هو أداة خبيرة وأشك في أنه يمكننا تغليفه في حزمة "تعمل فقط" للمطورين الذين ليسوا على دراية بالفعل بتصحيح أخطاء الطرق الغامضة التي يمكن لـ ADVANCED_OPTIMIZATIONS من خلالها تعطيل تطبيقك.

alexeagle نحن نعمل حاليًا على

حولت مشكلة tsickle 1 أعلاه إلى تقرير خطأ هناك.

مترجم الإغلاق متاح الآن على npm في جافا سكريبت خالص: 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 Compiler حيث تضيع الطرق الثابتة ، لدينا أمر sed حقًا نقوم بتشغيله على ملفات Angular js المبنية ، مع استبدال جميع الأسطر التي تتضمن كلمة رئيسية ثابتة بالسطر الذي يسبقه / ** nocollapse * / . إليك رابط خطأ Closure: https://github.com/google/closure-compiler/issues/1776

الزاوي

أكبر تغيير أجريناه على Angular هو جعله يستخدم مخرجات Tsickle المشروحة أثناء التجميع. اعتقدنا أننا فعلنا هذه المرة الأخيرة ، لكن كان لدينا خطأ حيث تم التخلص من الإخراج التوضيحي: D

كان هناك عدد قليل من الأماكن التي يشير إليها Angular الوظائف كسلاسل. تمت الإشارة إلى هذه الوظائف في أماكن أخرى باستخدام تدوين النقطة. وبناءً على ذلك ، تمت إعادة تسمية بعض المراجع بينما لم يتم تغيير أسماء أخرى. قمنا بتغيير Angular لاستخدام تدوين النقاط في كل مكان لهذه الوظائف ، بحيث يتم إعادة تسميتها دائمًا.

قمنا أيضًا بتحديث Angular / Tsickle لعدم إضافة تعليقات توضيحية لملفات d.ts.

لقد صنعنا لعبة Angular بشكل جيد مع ES6 ، لذا فهي تعمل في وضع غير مجمع. قمنا بتغيير بعض الأماكن حيث تم استخدام .apply على المُنشئ لاستخدام الكلمة الأساسية الجديدة.

تسيكل

لقد أصلحنا خطأ في tsickle حيث لم يتضمن CLI دائمًا جميع ملفات المصدر أثناء التعليق التوضيحي. يجب استخدام قائمة أسماء الملفات من برنامج 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
كلوتز: https://github.com/lucidsoftware/clutz

لذلك لدينا مثالان لهذا العمل ، بالإضافة إلى أننا نستخدم JSCompiler داخليًا في Google لذلك لدينا العديد من التطبيقات التي تقوم بذلك (على الرغم من استخدام نظام بناء Bazel وبعض قواعد Bazel التي لم يتم إصدارها بعد).

robwormaldmprobst هل يجب أن نحاول تجميع هذا الأمر بطريقة أكثر سهولة للتكرار للمستخدمين الخارجيين؟ لا أعتقد أنه يمكننا ادعاء النجاح وإغلاق هذه المشكلة حتى الآن.

مترجم إغلاق JS يبدو رائعًا حقًا. ومع ذلك ، فقد رأيت مشكلات حيث تنفد العملية من الذاكرة عند استهداف مشاريع AOT متوسطة الحجم عبر Rollup. هل واجهت هذا في الاختبار الخاص بك؟

لا يبدو أن إصدار Java يعاني من هذه المشكلة.

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

لقد سمعت ذلك أيضًا. كان علينا الاتصال بالعقدة بـ
--max-old-space-size = 4096 للحصول على بعض الأدوات للعمل في الماضي.

يوم الثلاثاء 20 سبتمبر 2016 الساعة 11:27 صباحًا Torgeir Helgevold [email protected]
كتب:

مترجم إغلاق JS يبدو رائعًا حقًا. ومع ذلك ، لقد رأيت القضايا
حيث تنفد العملية من الذاكرة مع استهداف AOT متوسط ​​الحجم
المشاريع. هل واجهت هذا في الاختبار الخاص بك؟

لا يبدو أن إصدار Java يعاني من هذه المشكلة.

google / close-compiler-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 غيغابايت ، لكن لا يزال لديّ نفاد الذاكرة في نموذج مشروعي.
نسخة جافا تعمل بالرغم من ذلك.

أوه ، هذا يبدو سيئًا :)
هل يمكنك تسجيل خطأ على https://github.com/google/closure-compiler/issues

يوم الثلاثاء 20 سبتمبر 2016 الساعة 11:52 صباحًا Torgeir Helgevold [email protected]
كتب:

لقد جربت max-old-space-size مع 8000 و 14000 على جهاز Mac بسعة 16 جيجابايت من ذاكرة الوصول العشوائي ،
ولكن لا يزال لدي نفاد الذاكرة في مشروع نموذجي.
نسخة جافا تعمل بالرغم من ذلك.

-
أنت تتلقى هذا لأنه تم تعيينك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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 الذي قد يكون مرتبطًا بخلل إنشائي ... حاول الإنشاء باستخدام بناء تنميط ليلي ... (للأسف ، لا يدعم ngc TS 2.1 ، لذلك عليك الرجوع والتقدم بين ذلك و 2.0.2).

qdouble Hm مثير للاهتمام .. هل تقول أنه قد يكون مرتبطًا
لأنه بحلول الوقت الذي يدخل فيه الكود الخاص بي في أرض المترجم التراكمي / الإغلاق ، يكون الرمز بتنسيق JS بالفعل.

thelgevold ah ، مع وجود خطأ يمكن أن يمنع إنشاء الكود الخاص بك إذا كان لديك الكثير من عناصر التحكم في النموذج والأشياء مع 2.0.2 ... إذا كانت ملفاتك بالفعل JS قبل أن تصادف الخطأ ، فقد يكون شيئًا ما آخر ... لكنني أفترض أنه يمكنك محاولة استخدام Typescript ليلاً لتحويلها إلى JS ومعرفة ما إذا كان يحدث أي فرق.

مرحباً يا رفاق ، كل هذا يبدو ممتعًا للغاية ونحن نتطلع إلى ذلك لتحسين أداء موقعنا على الإنترنت. ما هو الوضع الحالي للبنيات الزاويّة المخصصة التي تقوم بإنشائها. هل ستقوم ببناء Angular v 2.0.0؟

سأحاول الحصول على بعض التحديثات حول هذا الأمر لـ ngEurope ...

يوم الجمعة ، 7 أكتوبر ، 2016 ، 1:48 صباحًا. Gerard A Lamusse [email protected]
كتب:

مرحباً يا شباب ، كل هذا يبدو ممتعًا للغاية ونحن نبحث في هذا
لتحسين أداء موقعنا. ما هو الوضع الحالي ل
الزوايا المخصصة التي تقوم بإنشائها. سوف تقوم ببناء ل
الزاوي 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 لا _ لا _ يعيد تصدير هز الشجرة ، وأن الزاوي يتطلب الاستيراد من عمليات إعادة التصدير ، فهذه مشكلة كبيرة

كان تفكيري الواضح أوه ، tsickle! اعتقدت أنني سأقوم بتوجيه ngc -> tsickle -> webpack -> gcc Advanced (بدلاً من ngc فقط -> webpack -> gcc simple) فقط لتحقيق استيراد / طلب تحويلات tsickle إلى goog.require ، لذلك لا توجد حزمة ويب سهلة (أو أي تكامل آخر بخلاف Google bundle ، حقًا) هنا حاليًا

الزاوية الأساسية + النماذج + جهاز التوجيه + متصفح النظام الأساسي + الشائعة تستحوذ على حوالي 30٪ من الحزمة الرئيسية الخاصة بنا مع ngc + webpack2. هذا ~ 100 كيلو بايت مصغر ومضغوط ، أوه

أود أن أرى tsickle يعمل مع webpack ، كما هو واضح حتى فريق cli الزاوي يعتقد أن webpack هو خيار رائع. أنا منفتح على أي اقتراحات بشأن هذا. وإلا فسألقي نظرة أعمق على عمل @ngtools/webpack ؟)

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

يبدو أن موجز Twitter الخاص بهم يحتوي على بعض المحتوى.

احصل على Outlook لـ And roidhttps: //aka.ms/ghei36

في الجمعة 28 أكتوبر 2016 الساعة 12:52 صباحًا +0200 ، كتب "Steve Sewell" < [email protected] [email protected] >:

أي تحديث من ngeurope بأي فرصة؟

بعد إدراك أن اهتزاز شجرة webpack لا يؤدي إلى اهتزاز الأشجار ، وأن الزاوي يتطلب الاستيراد من عمليات إعادة التصدير ، فهذه مشكلة كبيرة

كان تفكيري الواضح أوه ، tsickle! اعتقدت أنني سأقوم بتوجيه ngc -> tsickle -> webpack (بدلاً من ngc فقط -> webpack) فقط لتحقيق استيراد / طلب تحويلات tsickle إلى goog.require ، لذلك لا يوجد تكامل webpack سهل هنا حاليًا

الزاوية الأساسية + النماذج + جهاز التوجيه + متصفح النظام الأساسي + الشائعة تستهلك حوالي 30٪ من الحزمة الرئيسية الخاصة بنا مع حزمة الويب 2. هذا ~ 100 كيلو بايت مصغر ومضغوط ، أوه

مفتوحة لأية اقتراحات بشأن هذا. وإلا فسألقي نظرة أعمق على عملj juddhttps: //github.com/jjudd ، لكني أكره إضاعة الوقت إذا كان هناك حل رسمي في الأفق

أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم tHubhttps: //github.com/angular/issues/8550#issuecomment -256791543 ، أو قم بكتم القراءة التالية

تحديث: أجرينا بعض المناقشات الجادة في ngEurope مع robwormald و hansl وآخرين.
يشكك @ pkozlowski-openource في أن يتبنى المجتمع الخارجي سلسلة أدوات جديدة ، بدلاً من تحسين المجموعة الحالية.
لذلك أعتقد أن الخطوة الأولى هي أن angular-cli ستعمل على تحسين webpack للقيام بعمل أفضل.

في الوقت نفسه ، ما زلت أرغب في الحصول على مشروع أساسي أساسي يوضح استخدام مترجم الإغلاق. @ steve8708 لست متأكدًا مما goog.require كسر المجمّع ، لأن مترجم الإغلاق _is_ المجمّع. لا تظهر أي كشوفات goog.require في ناتجها. jjudd هل أي شخص في Lucidchart مهتم بالتعاون لإخراج الاختراقات لدينا وتمكين المجتمع الخارجي من إعادة إصدار تطبيق 26k ng2؟

alexeagle حاليًا نستخدم حزمة الويب للعديد من الأشياء - التجميع ، وتقسيم الشفرة ، والمعالجة المسبقة ، والتفتيش ، والتجزئة ، و gzipping ، وغير ذلك ، على غرار ما يفعله CLI الزاوي والكثير من مبتدئين + webpack الزاوي مفتوح المصدر.

أود حقًا الاحتفاظ بحزمة webpack لكل ما تفعله (خاصة قبل الميلاد ، يمكننا الاستفادة من الكثير من المكونات الإضافية للمجتمع لجعل بعض المهام المعقدة بسيطة وقابلة للتكوين) بدلاً من إعادة تنفيذ كل ما نقوم به حاليًا (على سبيل المثال باستخدام gcc + gulp).

أحب أن أكون قادرًا فقط على تبديل tsickle بـ tsc لإضافة التعليقات التوضيحية لـ jsdoc أثناء النقل المطلوب لتصغير الوضع المتقدم (نستخدم حاليًا ملحق webpack gcc في الوضع البسيط للتصغير)

على الرغم من ذلك ، نقدر حقًا التحديث الخاص بك ، ومتشوق جدًا لتتبع التقدم الذي يحرزه فريق angular-cli باستخدام سلسلة أدوات webpack الخاصة بهم!

@ steve8708 ما هي الأدوات التي تريد أن تكون قادرًا على تشغيلها على كود ES6 الذي تم إغلاقه قبل أن تقوم بتسليمه إلى المكوِّن الإضافي لدول مجلس التعاون الخليجي؟

alexeagle شكرا على التحديث. سأتحدث مع الناس هنا وأرى ما هو الاهتمام هناك.

على سبيل المثال ، هل مثال الريبو الذي أنشأناه لهذا هو ما كنت تفكر فيه؟ https://github.com/lucidsoftware/closure-typescript-example

هذا يبدو وكأنه شيء رائع ل CLI. إنه يلتف Webpack ومجموعة من المكونات الإضافية الأخرى الموجودة والجديدة. سيكون رائعًا إذا كان بإمكان CLI استخدام مترجم Closure تحت الغطاء بدلاً من uglifier. يتم تجريده بعيدًا عن المستخدم في كلتا الحالتين.

jjudd ، نعم ، هذا أفضل ما لدينا الآن ، لكنه مثبت بإصدار معين (قديم) من ng2 وتبعياته ، أليس كذلك؟
نحتاج أيضًا إلى شرح كيفية استخدام العناصر الخارجية حتى تتمكن من الحصول على تبعيات غير متوافقة مع الإغلاق.

حقيقي. نحن نعمل بنشاط على الانتقال إلى أحدث إصدار من Angular في الوقت الحالي. نأمل أن يتم ذلك قريبًا جدًا. سأقوم بنشر تحديث عندما نقوم بذلك.

alexeagle حسنًا صراحة webpack مبنية على وحدات Commonjs / amd / es6 ، لذلك لا تعمل الكثير من الميزات بشكل صحيح (إن وجدت) إذا لم تكن الوحدات بهذا التنسيق. بعض الأشياء السريعة التي تتبادر إلى الذهن

• محمل url. نقوم باستيراد الأصول بتنسيق الكتابة المطبوعة (أو html) كـ require('./asset.png') وببساطة عن طريق القيام بحزمة الويب هذه ، تتعامل مع نسخ الصور وتجزئتها وضغطها وتحميلها عند الحاجة
• تقسيم تلقائي للكود (على سبيل المثال ، استخدام محمل توجيه angular2 مثل هذا ) وأي استيراد System.import آخر في جميع أنحاء الكود الخاص بك لسهولة التحميل البطيء لأي محتوى
• لوادر أخرى متنوعة - على سبيل المثال ، نستخدم محمل الاستيراد لمادة angular2 حيث تحتوي المادة حاليًا على مراجع نافذة للعثور على مساعدين مطبوعين مثل __extends لذلك يجب علينا إعادة كتابة ذلك إلى global ( مثال ). حتى أشياء مثل هذه تعمل فقط بأناقة (أو أقل إختراقًا) مع حزمة الويب عندما يكون لديك التعامل مع حزمك كما هو مقصود
• العديد من المكونات الإضافية الأخرى - على سبيل المثال ، سينتج المكون الإضافي html index.html الأساسي الخاص بنا بعد تشغيل البنية / الحزمة الكاملة نظرًا لأنه من القيام بذلك فهو على دراية بملفات جافا سكريبت الإدخال التي تم إنشاؤها (بما في ذلك المسارات والتجزئة الكاملة) وينتج الجذر الخاص بنا html مع عناوين url النصية الصحيحة مع التجزئة ، وما إلى ذلك بشكل مناسب

بصراحة ، لقد نفذت هذه الأشياء نفسها (أو ما شابهها) عدة مرات مع أي شيء بدءًا من make / jakefiles ، و grunt ، و gulp ، وما إلى ذلك ، لكنني لم أحصل أبدًا على تجربة أدوات بناء قوية وسلسة مثل استخدام webpack (خاصة لـ مقدار الكود الذي يجب أن تكتبه وتحافظ عليه للبناء الخاص بك) ، لذلك أود أن أرى tsickle يسمح بتنسيقات الوحدات النمطية الأكثر شيوعًا (في الأراضي المفتوحة المصدر) التي يمكن أن تتكامل مع أدوات مثل حزمة الويب

tl ؛ dr ، webpack يعتمد فقط على استخدام استيراد Commonjs أو amd أو es ، ولديهم نظام رائع جدًا من اللوادر والمكونات الإضافية التي يمكنها القيام بالكثير من الأشياء الرائعة طالما أن webpack يمكنه فهم الوحدات النمطية الخاصة بك في أي من جافا سكريبت الشائع ، والتي للأسف لا تتضمن أي وحدات goog.*

lmk إذا كان هناك أي شيء آخر يمكنني المساعدة في الإجابة عليه هنا أو حتى مساهمات برمجية يمكنني تقديمها لمحاولة استخدام tsickle مع أدوات أخرى مثل حزمة الويب. أنا متحمس جدًا للحصول على هذا الأمر مهما كان ذلك ممكنًا!

و شكرا!

@ steve8708 السبب في قيامنا حاليًا بتسليم بناء جملة goog.module لإغلاق المحول البرمجي هو أنه يحتوي على أخطاء / ميزات مفقودة لوحدات ES6 النمطية. في المرة الأخيرة التي تحققت فيها من عدم وجود دعم لـ export * على سبيل المثال. أشار الفريق إلى أنهم غير مهتمين بدعم وحدات ES6 لأنها لا تعمل أصلاً في معظم المتصفحات.

إذا كنت بحاجة إلى أخذ رمز TS من خلال هذه الخطوات قبل التجميع / اهتزاز الأشجار / التصغير باستخدام مترجم الإغلاق ، فسنحتاج إلى إصلاح كل دعم وحدة ES6 في مترجم الإغلاق. لا أعتقد أن أي شخص يمتلك هذا الآن.

من الجيد أن تعرف ، شكرًا alexeagle

لقد وجدت للتو بعض المستندات التي تقترح أن مجلس التعاون الخليجي يدعم وحدات Commonjs أيضًا. سأختبره قليلاً وأكتشف ما إذا كان قد تم تنفيذه أكثر أو أقل من عربات التي تجرها الدواب من وحدات es6 حاليًا.

إذا كان الأمر كذلك ، فسوف أتحرك وأرى ما إذا كان من الممكن جعل تحويل وحدة goog اختياريًا في tsickle وما إذا كانت هناك طريقة للحصول على فوائد التصغير المتقدم لدول مجلس التعاون الخليجي باستخدام التعليقات التوضيحية من نوع jsdoc التي تم سحبها من الكتابة المطبوعة ولكن باستخدام وحدات Commonjs أو es6. أعتقد أن هذا سيكون بالتأكيد لطيفًا لنفسي وبقية المجتمع!

شكرا مرة أخرى على المعلومات ، إنها مفيدة للغاية!

ناقش المزيد هنا شخصيًا ... إذا كان الخطأ الوحيد في مترجم الإغلاق هو export * ، فيمكننا بسهولة إنشاء خيار tsickle لتسطيح ذلك إلى export {symbol1, symbol2, ...} في خطوة ما بعد المعالجة. يمكننا أيضًا إضافة تعليقات JSDoc التوضيحية (وتضمينها في توزيعات ES6 الخاصة بنا).

alexeagle سيكون من الرائع الحصول على تعليقات jsdoc في توزيعات ES6!

من بعض الاختبارات اليوم ، وجدت أن tsickle قام بالفعل بتحويل export * إلى تنسيق export { a, b, c } لوحدات es6 ، لذا فهذه أخبار رائعة!

والأفضل من ذلك ، لقد قمت باستنساخ tsickle محليًا وعلقت على التحويل إلى وحدات goog وتمكنت من الحصول على tsickle + gcc المتقدم الذي يعمل بشكل مثالي مع webpack build الخاص بنا كما هو مأمول!

أدى هذا إلى خفض حجم الحزمة الرئيسية بنسبة 15٪ بالكامل ، وهذا دون شرح أي شيء @angular/* حتى الآن. يبدو هذا مثيرًا للغاية وواعدًا

علاوة على ذلك ، من خلال التحقيق الذي أجريته اليوم ، أرى أنه عندما تقوم بالترجمة باستخدام وحدات es6 ، لا يتم استبدال أي منها بـ goog.require ، لا يتطلب الأمر سوى إجراء مكالمات. هذه أخبار جيدة حقًا لأنها تعني أن المشاريع يمكن أن تستخدم tsickle كما هي بالفعل اليوم مع الأدوات التي تدعم وحدات esmodules مثل rollup و webpack2 طالما أنها تحل محل _all_ commonjs require المكالمات باستيراد es6.

لحسن الحظ ، جعلت ts 2.0 هذا الأمر أسهل بكثير باستخدام declare module '*' ، مما يلغي الحاجة إلى استخدام require للتعليمات البرمجية غير المطبوعة

أنا متحمس حقًا لمعرفة مقدار ما يمكننا توفيره عندما تحتوي توزيعات @angular/* es على تعليقات توضيحية من tsickle أيضًا! خاصةً في حين أن webpack2 لا يزال لا يهز الشجرة ويعيد تصدير المدخرات الناتجة عن إزالة الكثير من الأكواد الأساسية الزاويّة المجمعة ولكن غير المستخدمة / الشائعة / وما إلى ذلك هنا قد تكون كبيرة حقًا!

قررت أن أجرب هذا أيضًا.

تم نسخ أحدث 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 source بدون export * هنا؟

2) الكلمات الرئيسية للإغلاق في تعليقات شفرة المصدر الزاوي التي تسبب أخطاء في التجميع

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. رغم الأمل!

الآن بعد أن أصبحت العلاقات العامة متاحة حتى تتمكن من استخدامها

    "@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

تضمين التغريدة

أحاول القيام بذلك الآن وعند استخدام إصدارات -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 في الكود الزاوي / التطبيق يعمل ....

فيما يلي نموذج لخطأ:

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 يسمح بذلك ، يدعمه التراكمي و 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 ، إلخ) المسارات الصحيحة لدعم دول مجلس التعاون الخليجي

سأعطيها مزيدًا من التفكير ولكن في الوقت الحالي ، يبدو أن خيارات دول مجلس التعاون الخليجي المتقدمة قد لا تكون متاحة للمستخدم العام في أي وقت قريب ما لم يكن لدى أي شخص آخر أي أفكار أخرى

هل من الممكن أن يكون لديك ناتج ngc JS مع تدوين اليد الطويلة للواردات لحماية المستخدم من استخدامها في كود TypeScript الخاص به.

ثم كجزء من الإصدار A2 ، هل تفعل الشيء نفسه بالنسبة للشفرة الزاوية؟ هل تنشر نسخة مع واردات طويلة؟

هذه فكرة جيدة - داخليًا لدينا تحويل tsickle إلى goog.module
بناء الجملة ، لذلك يجب أن نكون قادرين على استخدام تحويل مختلف لإعطاء صريح
الواردات من /index.js

يوم الأربعاء 30 نوفمبر 2016 الساعة 11:35 صباحًا Torgeir Helgevold [email protected]
كتب:

هل سيكون من الممكن الحصول على إخراج ngc JS مع تدوين العقرب الطويل لـ
يستورد لحماية المستخدم من استخدامها في كود TypeScript الخاص به.

ثم كجزء من الإصدار A2 ، هل تفعل الشيء نفسه بالنسبة للشفرة الزاوية؟ في الأساس
نشر نسخة مع واردات طويلة الشكل؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/angular/angular/issues/8550#issuecomment-263971981 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAC5Iy255poYsJTn8ZdBAgVZWbagFwzAks5rDdARgaJpZM4IaZIi
.

آه هذه فكرة رائعة!

أتساءل رغم ذلك ، هل / هل يمكن أن يغطي ذلك أيضًا المكتبات غير الزاوية؟ أي هل يقوم tsickle بتحليل الوحدات النمطية غير المطبوعة / الزاوية بحيث يمكنه أيضًا تحويل import { foo } from 'other-lib' إلى import { foo } from 'other-lib/index' عند الحاجة؟

وبالمثل ، هناك عنصر آخر من عناصر دقة الوحدة التي تستخدمها بعض أدوات التحميل الرئيسية في محاكاة دقة وحدة العقدة إذا كان other-lib يحتوي على حقل main في الحزمة الخاصة بهم. json ، لنقل الإشارة إلى main.js ، هل سيكون أيضًا (من الناحية النظرية ، إذا تم تنفيذه) قادرًا على تحويل الواردات من تلك الحزمة إلى import { foo } from 'other-lib/main' ؟

يعتمد هذا في الغالب فقط على مدى عمق tsickle الذي يجتاز الكود الخاص بك عند تشغيله من سطر الأوامر. يبدو لي أنه إذا لم يتم اجتياز كل شيء ، فستظل مشكلة حل الوحدة هذه مشكلة لأي شخص آخر قد يستخدمه أشخاص من طرف ثالث

إذا كان كل هذا ممكنًا ، فسيكون ذلك رائعًا جدًا ويعني أنه يمكن إعادة القدرة على استخدام tsickle على رادارنا وهو أمر مذهل!

بشكل عام ، يمكن تحسين المكتبات التي تتم صيانتها بعناية فقط عن طريق الإغلاق ، مما يكسر الآخرين. لذلك سيكون الاستخدام المعتاد

• يقوم الإغلاق بتجميع الكود الخاص بك ، Angular وأقسامه (خاصة rxjs) في حزمة واحدة أو أكثر
• إعطاء ملفات خارجية للإغلاق للمكتبات الأخرى التي تحتاجها للتفاعل مع / من حزمة الإغلاق
• قم بتحميل حزم مكتبة أخرى باستخدام توزيع js المصغر في علامة نصية منفصلة

هذا ما نفعله داخل Google أيضًا. لذلك لا ينبغي أن تكون هناك حاجة لتشغيل tsickle ، فقط ngc.

آه ، أشكركم على ملاحظةalexeagle!

فقط في حال حالفنا الحظ ، طلبت من TS القيام بذلك:
https://github.com/Microsoft/TypeScript/issues/12597
في غضون ذلك ، ربما يمكننا القيام بذلك بسرعة ، أنا أحاول ذلك الآن. ها هي المشكلة لذلك:
https://github.com/angular/tsickle/issues/288

تحديث: تم حل هذه المشكلة tsickle. بناء الزاوي من هذا الفرع:
https://github.com/alexeagle/angular/tree/closure
أنتج الآن توزيعة ES6 بكل ما هو صريح import {} from '@angular/core/index'

المشكلة التالية هي أننا بحاجة إلى توزيعة متوافقة لـ rxjs. jayphelps كان يبحث في قصة تغليف rxjs ، والتي تم تأجيلها إلى ما بعد 5.0.0 النهائي. ربما لا نزال بحاجة إلى توزيعة تجريبية مخصصة لـ rxjs في هذه الأثناء أيضًا.

هذا حقا عمل رائع alexeagle

لقد شورت مشروعك وأضفت بعض العينات "المتقدمة". النبأ العظيم هو أن جزء مترجم الإغلاق شفاف حقًا وليس في طريقنا على الإطلاق.

أضفت نماذج ديناميكية (نماذج تفاعلية) وعينات عرض تكراري متكرر وكل شيء يعمل بشكل جيد.

كانت التعديلات التي كان عليّ إجراؤها هي بعض الإضافات إلى تكوين برنامج التحويل البرمجي للإغلاق للوصول إلى توجيهات النماذج و ngIF و ngFor وما إلى ذلك.

شوكة:
https://github.com/thelgevold/closure-compiler-angular-bundling/tree/add-samples

لقد نشرت نسخة من النموذج هنا أيضًا:
http://www.syntaxsuccess.com/a2-closure/

رائع ، شكرًا لانتقاء هذا بسرعةthelgevold
بالنسبة للآخرين الذين يشاهدون الخيط: لقد قمت بتحديث مثال الريبو اليوم ، لدينا إعداد مترجم لإغلاق العمل مرة أخرى ، والآن لا يوجد برنامج نصي منفصل متعدد التعبئة. تم تضمين Zone.js في حزمة الإغلاق.

أعتقد أن الخطوات التالية هي تجربة ذلك في بعض سيناريوهات العالم الحقيقي. ايونيك تفعل هذا ايضا ثم في وقت ما من الشهر المقبل سنحاول الحصول على فريق Closure Compiler في غرفة معنا وحرق أكبر مشكلات قابلية الاستخدام. في هذه الأثناء ، تساعد mhevery في توضيح الكود الذي تم الاحتفاظ به ولكن كان يجب التخلص منه.

سؤال:
ألقيت نظرة على تضمين libs الطرف الثالث عند القيام بتجميع الإغلاق.

يتمثل التحدي الذي يواجه تسوية مسارات الاستيراد باستخدام برنامج التحويل البرمجي TypeScript في أنه من المرجح أن يتم نشر libs الطرف الثالث بمصدر JS فقط.
هذا يجعل الأمر أكثر تعقيدًا لتطبيع واردات البرميل بدون index في نهاية المسار.

هل كانت هناك أي مناقشات حول عكس التوصية لصالح العقدة moduleResolution ؟

أعتقد أنه لن يكون من السيء استخدام moduleResolution الكلاسيكي بدلاً من ذلك وإدراج index في مسارات الاستيراد.

أظن أنه قد يكون هناك عقوبة أداء أثناء التجميع في المشاريع الكبيرة. خاصة إذا كان على المترجم إجراء عمليات بحث عن كل استيراد لاكتشاف ما إذا كان عليه إعادة كتابته ليكون متوافقًا مع استيراد مترجم الإغلاق.

ومع ذلك ، فإن تجميع برنامج التحويل البرمجي للإغلاق (ADVANCED_OPTIMIZATION) بمعزل عن غيره عادة ما يكون خطوة تستغرق وقتًا طويلاً. ربما لا يكون الوقت الإضافي ملحوظًا؟

أفكار؟

أوافق على أن وقت الترجمة الخاص بنا يتأثر ببحث الفهرس الذي أضفته إليه
tsickle - لكل عملية استيراد يتعين علينا إجراء حل وحدة مرة أخرى.
داخليًا ، نقوم بتحويل وحدات JS الشائعة إلى goog.module / goog.require - I.
تخيل أنه سيكون بطيئًا جدًا بالنسبة لنا للقيام بالخطوة الإضافية في التطوير
الوضع.

يمكننا مناقشة مسألة دعم دقة نمط node_module بعد ذلك
أسبوعًا ، لدينا يوم هاكاثون مع فريق Closure Compiler.

ومع ذلك ، حتى لو فهم مترجم الإغلاق بناء جملة الوحدة لـ
مكتبات الجهات الخارجية ، يتم كسر الشفرة النموذجية بواسطة ADVANCED_OPTIMIZATIONS ،
يرجع ذلك إلى حد كبير إلى بناء جملة الوصول إلى الخاصية (تمت إعادة تسمية بناء الجملة إلى مربع
بناء الجملة ليس كذلك). لذلك أعتقد أن مكتبات الطرف الثالث يجب أن تبقى
خارج تجميع الإغلاق. داخليًا ، نأخذ فقط -min.js
توزيعة وتسلسلها في نهاية JS المجمعة للإغلاق.

لقد تخيلنا أنه سيكون من الرائع أن يتم إلغاء الاشتراك في ملف أو حزمة ما
من تحسينات الإغلاق. إحدى الطرق العملية التي يمكنني تخيلها للقيام بذلك هي
لإضافة "closeCompilerCompatible: true" إلى package.json للمكتبات
التي تحققت من إغلاقها المتقدم التحسين المتوافق. ثم بناء
يمكن لأداة تحديد المكتبات التي تم تجميعها في الحزمة ، مقابل.
تلك التي يتم حلها باستخدام عوامل الإغلاق الخارجية.

يوم الخميس ، 12 يناير 2017 الساعة 6:59 مساءً Torgeir Helgevold [email protected]
كتب:

سؤال:
ألقيت نظرة على تضمين libs الطرف الثالث عند القيام بتجميع الإغلاق.

التحدي هناك لتسوية مسارات الاستيراد باستخدام TypeScript
المترجم هو أنه من المرجح أن يتم نشر libs الطرف الثالث مع JS فقط
مصدر.
وهذا يجعل من الصعب تطبيع واردات البراميل بدون مؤشر
في نهاية المسار.

هل كانت هناك أية مناقشات حول عكس التوصية إلى
تفضل وحدة العقدة

أعتقد أنه لن يكون من السيئ للغاية استخدام الكلاسيكية بدلاً من ذلك
moduleResolution ودائمًا تضمين الفهرس في مسارات الاستيراد.

أظن أنه قد تكون هناك عقوبة أداء أثناء التجميع في
مشاريع كبيرة. خاصة إذا كان على المترجم أن يقوم بالبحث عن كل ملف
استيراد لاكتشاف ما إذا كان يجب إعادة كتابته ليكون متوافقًا مع الإغلاق
واردات المترجم.

ومع ذلك ، فإن تجميع مجمع الإغلاق (ADVANCED_OPTIMIZATION) بتنسيق
عادة ما تكون العزلة خطوة تستغرق وقتًا طويلاً. ربما الوقت المضاف ليس كذلك
كل هذا ملحوظ؟

أفكار؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/angular/angular/issues/8550#issuecomment-272348788 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAC5I49thgsBW1VGc3oyFVvEchxI2D6Zks5rRuivgaJpZM4IaZIi
.

شكرا على الرد. أنا أستمتع بمتابعة التقدم في هذا المشروع.

نعم ، أرى بالتأكيد بعض التحديات عند الدمج مع libs الطرف الثالث - خاصة تلك التي تمت كتابتها دون وضع مترجم الإغلاق في الاعتبار. يعجبني اقتراح تضمين نوع من علامة توافق مترجم الإغلاق.

تجربتي مع مترجم الإغلاق أنه من المحتمل أن يقدم تحسينات لا تصدق ، لكنه يفرض عليك بعض الاتفاقيات. ما زلت أراها كأداة خبيرة ، لكنني أتساءل عما إذا كانت هناك طرق في ngc لتبسيط الأمور عن طريق إنشاء كود يتوافق مع بعض هذه الاصطلاحات. Externs كل حالة على حدة بناءً على ثوابت مكتبات معينة ، ولكن حالة استخدام أخرى شائعة هي استدعاءات http.

عند التعامل مع مكالمات http ....
بالطريقة التي أراها ، سيتعين علينا "قوس مربع" حماية بعض خصائص النموذج لدينا لمنع المترجم Closure من تقصير أسماء الخصائص في الإشارات إلى كائن الحمولة. وبخلاف ذلك ، لن تتطابق الإصدارات المختصرة مع قيم وقت التشغيل من حمولة http الفعلية.

لدي خصائص محمية بشكل عام حسب الحاجة باستخدام رمز القوس المربّع {'firstName': 'Joe'} .
يعمل هذا النهج جيدًا بالنسبة لي ، ولكن قد لا يحب بعض الأشخاص أنه يتعين علينا كتابة رمز مثل هذا. ربما يمكن أن يكون مصمم الديكور أو ما شابه ذلك بمثابة إشارة إلى ngc لإنشاء JS بهذا التنسيق في الحالات التي يتم فيها حماية أسماء الخصائص mush؟

داخل tsickle جعلناها كذلك
إعلان واجهة المستخدم {firstName: string؛ }
(مع "التصريح") يخبر المترجم Closure بعدم إفساد استخدام ملف
حقل "الاسم الأول".

يتوافق هذا بشكل غامض مع كيفية عمله بالفعل في TS ، حيث "يعلن"
تُستخدم لتمثيل أنواع الأشياء الموجودة خارج رمز TS الخاص بك.

evmar هذا ممتاز! شكرا لإخباري عن هذا.

لقد قمت بتحديث مفترقتي لاستخدام بناء اللقطة الجديد من الريبو الزاوي. https://github.com/thelgevold/closure-compiler-angular-bundling

بقدر ما أعرف ، فإن التبعية غير القياسية الوحيدة في هذه المرحلة هي بناء rxjs مخصص.

لتجربة سيناريوهات أكثر واقعية ، بدأت في نقل مكونات العرض التوضيحي الخاصة بي إلى شوكة مجمع الإغلاق.

في ما يلي بنائين إذا كنت مهتمًا بإجراء مقارنة بين بنية تجميع قياسية وبناء مجمع إغلاق للمكونات الخاصة بي:

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

لست معروفًا بمهارات css ، لذا فإن العرض التوضيحي يفتقر بشدة إلى التصميم ، ولكن من المثير للاهتمام مقارنة حجم wt للبناءين:

فيما يلي إحصائيات الحجم:
تراكم: 130 كيلو
الإغلاق: 79.2 كيلو

في بناء Closure ، يمكنك أيضًا تخطي Core-js shim إذا كان متصفحك يدعم es6 (Chrome ، Edge ، إلخ). يتطلب بناء Rollup الرقاقة بغض النظر عن دعم es6 في المتصفح. هذا من الآثار الجانبية لعدم هز الديكور.

سوف أتوسع في هذا العرض التوضيحي بمرور الوقت. يستخدم حاليًا الموجه والنماذج والنماذج التفاعلية.

حتى الآن ، كان من السهل نسبيًا كتابة التعليمات البرمجية مقابل مترجم الإغلاق. المرة الوحيدة التي اضطررت فيها إلى إجراء تعديلات خاصة لإنجاحها كانت في العرض التوضيحي "للشبكة القابلة للفرز". تقوم الشبكة بإجراء عمليات بحث ديناميكية حسب اسم العمود الذي لا يتوافق مع تشويه أسماء الخصائص.

كما تمت مناقشته سابقًا ، قد يكون من الممكن منع تشويه الخصائص باستخدام واجهة ذات declare
السابق:

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

قد تكون هذه مشكلة من جانبي ، ولكن لا يبدو أن الواجهة مع declare تترك إشارات لمجمع Closure الذي سيمنع التشويه. كحل بديل ، كنت "قوسًا مربعًا" أحمي أسماء الممتلكات. يعمل هذا بشكل جيد ، ولكن سيكون من الجيد حله باستخدام الواجهة بدلاً من ذلك.

فيما يلي إحصائيات الحجم:
تراكم: 130 كيلو
الإغلاق: 79.2 كيلو

أنا متفاجئ. بعد أن استخدمت مترجم الإغلاق في الوضع المتقدم لسنوات ، كنت أعتقد أن الفرق سيكون أكبر ... لكنني أعتقد أن Angular هو إطار عمل كبير.

في حالتي ، يكون الانقسام بين Angular vs Application code / rxjs 70/30 تقريبًا.

هنا هو عرض مستكشف الخريطة المصدر في الحزمة: http://www.syntaxsuccess.com/closure-compiler-demo-map

يعتقد @ b-Strauss Misko أنه يجب التخلص من نصف وزن 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 يمكن أن يقوم بعمل أفضل في تحسين الدعائم المقتبسة من خلال مزيج من مرجع واحد كامل الطول ومراجع داخلية مختصرة لنفس الخاصية.

أعتقد أن العناصر الخارجية أقل تحسينًا لأنها لن تلمس أي إشارات إلى اسم الخاصية. المعنى 50 من المراجع إلى firstName ستبقى كاسم أول ، بينما قد تترك الأقواس المربعة مرجعًا عامًا واحدًا مثل firstName وتفسد المراجع الداخلية الـ 49 الأخرى.

thelgevold هذا صحيح ، فإن نهج externs يشير إلى اسم الخاصية هذا على أنه غير قابل لإعادة التسمية في كل مكان.
ليس لدينا أي طريقة لإعادة كتابة الوصول إلى الوصول المقتبس تلقائيًا ، على الرغم من أنني أفترض أنه مع نظام النوع يمكننا رؤية declare interface ومعرفة وقت القيام بذلك.

لكن بعد الضغط ، قد لا يهم؟ إذا دخل firstName إلى القاموس في رأس الملف المضغوط ، فقد لا يحدث فرق كبير في عدد مرات الإشارة إليه في الكود.

FWIW هذا هو النهج الذي نتبعه الآن داخليًا في Google. لكن أعتقد أنه يجب علينا تجربة اقتراحك إذا حصلنا على الوقت.

أنا متأكد من أن الإغلاق لا يحسن الدعائم المقتبسة بأي شكل من الأشكال. يؤدي الإغلاق فقط إلى إزالة علامة القوس المربع من هذا: model['firstname'] إلى هذا x.firstname .

طريقة AFAIK "النظيفة" مع الملفات الخارجية وطريقة التدوين المربع تعطي نفس النتيجة.

المشكلة هي أن notModel.firstName سيكون أيضًا y.firstname بدلاً من y.z

يجب أن يكون الإغلاق قادرًا على التمييز اسميًا بين أنواع هذه الحالات من خلال الأنواع المتوفرة في العناصر الخارجية. هذه هي الطريقة التي عملت بها في العالم "العالمي" القديم. ليس لدي أي فكرة عن كيفية إنشاء عناصر خارجية للفصول التي لها نفس الاسم ولكنها تأتي من وحدات مختلفة.

alexeagle ربما أنت على حق. قد لا يكون هناك الكثير من المكاسب بعد gzip.

من المحتمل أن يكون الأمر معقدًا أيضًا لأنه من المرجح أن تكتشف كل المراجع "نفسها" firstName وتعيد كتابتها إلى ['firstName'] طوال الطريق. وإلا فسيكون هناك مزيج من الترميز .firstName و ['firstName'] ، والذي سينقطع في وقت التشغيل.

@ b-Strauss Closure سيحول ['firstName'] إلى .firstName. ومع ذلك ، إليك نظرية التحسين وراء [''] مقابل الخارجين: 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 للخارج.

@ b-Strauss شكرًا على مشاركة هذه التجربة.

كان تعليقي الأصلي أكثر حول كيفية قيام [''] بتحسين مراجع متعددة لنفس خاصية MyModel.firstName . لا يتعلق الأمر كثيرًا بتحسين نفس الأسماء المتقاطعة عبر كائنات نموذج مختلفة.

ما أفهمه هو أنه إذا كان لديك 10 MyModel().firstname refs في شفرتك ، فإن استخدام [''] قد يسمح لـ Closure بإنشاء اسم مستعار داخلي قصير. بهذه الطريقة يكون الحجم الصافي أصغر نظرًا لأنه يحتفظ بالاسم الأول حيث يتوقعه الكود الآخر ، ولكنه يستفيد من الاسم الأقصر للمراجع الخاصة / المحلية. أفهم أن الخارج لن يمنحك هذه الفائدة لأنه يترك كل المراجع وحدها.

@ b-Strauss كانت خطتي هي معالجة هذا في https://github.com/angular/tsickle/issues/352 ، عن طريق تغيير اسم الخارجيين ثم التعرّف محليًا. أي لملف 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 Add-on Libraryakers (على الرغم من أنه ربما لا يكون النظام البيئي الأوسع) للتحقق من أن موادهم تعمل مع Closure. حدث نفس الشيء خلال الأشهر القليلة الماضية فيما يتعلق بـ AOT ، في أوائل الخريف ، قالت معظم المكتبات الإضافية "AOT؟" لكن اليوم معظمهم الذين أتعثر عليهم لديهم أشياء تعمل مع AOT أو يدركون جيدًا ويتجهون في هذا الاتجاه.

إذا كان أي شخص يتابع هذا العمل في العديد من المستودعات المرتبطة بهذه المشكلة خلال العام الماضي ، أعتقد أن أحدث ما رأيته أعلاه لا يزال يشير إلى حزم "-builds" ، والتي كانت ضرورية حتى وقت قريب. ولكن الآن يتم شحن Angular 4 RC بوحدات ES2015 ، لذلك لم يعد ذلك ضروريًا. إليك فرع قمت بتحديثه للعمل مع الأحدث ، في عملية اللحاق بفهم ما يجري مع استخدام Closure.

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

يبدو الأمر كما لو أننا على وشك الحصول على سلسلة بناء زاوية من الدرجة الإنتاجية تتكون من ngc فقط (مع tsc في الداخل) بالإضافة إلى الإغلاق. هذا مكدس قصير لطيف.

لقد قمت بنشر المستودع التالي الذي يوضح كيفية استخدام 4rc.2 و ngc (AOT) و Closure Compiler:

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

من الناحية التكنولوجية ، هذا ليس لديه الكثير ليقدمه على أليكس ، لكن له هدفًا مختلفًا. أحاول أن أجعل هذا المستودع يحتوي على الكثير من التعليقات والنصوص التي تشرح كيف ولماذا الأشياء. لذلك ، لا تتردد في فتح مشكلة بشأنها ، إذا كان هناك أي شيء لم يتم شرحه بشكل كافٍ في التعليقات أو README.

nosachamos Wild guess: شيء ما في toolchain (ربما tsickle أو Closure؟) لم يتوقع معلمة باسم this . اقتراحي هو:

• قم بتحرير نسختك المحلية من مصدر RxJS ، وتغيير اسم المعلمة ، وتأكيد الإصلاح. إذا كان الأمر كذلك إذن ...
• ضع إصدارًا (أو حتى PR) إلى RxJS لإعادة تسمية this وأي معلمات this مماثلة. نأمل أن يرى فريق RxJS ميزة هذا التغيير ؛ ربما تساعد كلمة جيدة من فريق Angular ( alexeagle ؟) حول مثل هذه المشكلة.
• ضع مشكلة في حالة repro بسيطة إلى Closure ، حول المعلمة المسماة this ... ولم يتم إعادة طرحها هناك ، ابحث في مكان آخر في سلسلة الأدوات (tsickle؟).

kylecordes Ops ، لقد وجدت

للتسجيل ، كانت مشكلتي أن الحجة المسماة "هذا" تمت إزالتها أثناء الترجمة.

اتضح أن الإغلاق كان يستدعي هذه الوظيفة باستخدام call ، لذلك تم تعيين this بهذه الطريقة بالفعل ولا يلزم تمريره. إذا أعدت تسمية "this" إلى "this2" ، فإن الوسيطة هي أبقى. أعتقد أن جهاز التحويل هو أذكى مما كنت أعتقد.

كانت مشكلتي ضمن تأثيرات ngrx ، وليست rxjs. يصل Ngrx / effects إلى التأثيرات من خلال أسمائها ، باستخدام تدوين الأقواس ، والذي يتم كسره بواسطة مترجم الإغلاق عندما يعيد تسمية كل الأشياء. لمنع هذه المشكلة ، في مُنشئ الفئات التي تحتوي على تأثيراتك ، عيّن أسمائها إلى "هذا" باستخدام تدوين الأقواس:

export class MyEffects {

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

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

}

لذلك أنا على وشك أن أعمل على تطبيق حقيقي باستخدام مكدس ngrx. أنا أكتب ما أعتقد أنه آخر دليل خارجي مطلوب لحالتي. إذا كان كل هذا يعمل بشكل جيد ، فسوف أقوم بإنشاء فرع على نموذج التطبيق هنا مع مكدس ngrx كعرض توضيحي. أنا أستخدم مفترقتي الخاصة من ngrx / core و ngrx / store بينما لم يتم دمج العلاقات العامة الخاصة بي لتوسيع صادرات أحرف البدل ، ولكن بخلاف ذلك ، أعتقد أن هذا سوف يسير على ما يرام.

سأبقيكم على اطلاع.

هل يمكنك تقديم خطأ ضد tsickle بمزيد من المعلومات حول مشكلة this ؟ هدفنا هو أنك لست بحاجة إلى إعادة تسمية متغيرات مثل هذه يدويًا.

هل من الممكن إصلاح ngrx لعدم استخدام الأقواس؟

nosachamos بناءً على تعليقك المحذوف ، وتعليقي الذي ربما يجب حذفه ، هل هناك أي مشكلة للإبلاغ عنها؟ (لكل evmar )

@ kylecordes ربما ،
ولكن ما أعتقد أنه يحدث هو أن المترجم يمكنه اكتشاف الوظيفة التي تم تعيينها بواسطة الاستدعاء call . لذلك يمكنه في هذه الحالة إزالة الوسيطة بأمان ، حيث أن this سيكون كل ما يتم تمريره إلى call . لن يكون هذا صحيحًا إذا تمت إعادة تسمية الحجة ، لذا فهي تحافظ على الحجة. أعتقد أنه في "هذه" الحالة بالذات ، فإن المترجمة على ما يرام. في الواقع ، لا تؤدي إعادة تسمية الوسيطة إلى حل المشكلة ، حيث كانت المشكلة الحقيقية هي الوصول إلى الأقواس.

evmar أعتقد ذلك. يعد الوصول إلى القوس هذا أمرًا أساسيًا لعملياتهم ولكني أظن أن التعليق التوضيحي للقاموس الأساسي مع التعليق التوضيحي للإغلاق

لاحظ أن أي تعليق توضيحي من نوع Closure مضاف إلى رمز TS يتم تجريده بواسطة Tsickle ، لذا فإن إضافة dict هناك لن يساعد.

كانت مشكلتي ضمن تأثيرات ngrx ، وليست rxjs. يصل Ngrx / effects إلى التأثيرات من خلال أسمائها ، باستخدام تدوين الأقواس ، والذي يتم كسره بواسطة مترجم الإغلاق عندما يعيد تسمية كل الأشياء. لمنع هذه المشكلة ، في مُنشئ الفئات التي تحتوي على تأثيراتك ، عيّن أسمائها إلى "هذا" باستخدام تدوين الأقواس:

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 أوه ، أنا أقوم

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

و

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

لذلك أحصل على ES6 فقط ، ولا توجد وحدات goog.modules .. لذا يبدو أن كل شيء يعمل على النحو المنشود ، وأحصل على التعليقات التوضيحية للإغلاق. هذا من أجل RxJs. بالنسبة للحزم التي تتفاعل مع الزاوية (مكونات ، وحدات ، إلخ) ، يتم تعيين skipMetadataEmit على false .

nosachamos كما أفهم ، لا يمكن لخطوة tsickle أن تفعل شيئًا ، ولن تفعل شيئًا عند تشغيلها عبر ngc ، إلا إذا كنت تستخدم "module": "common" . يفرض Tsickle هذا القيد عند تشغيله بواسطة CLI الخاص به ، فهل يكتسب القدرة على العمل مع إخراج الوحدة النمطية es2015 عند تشغيله عبر ngc ؟ هل ترى JSDoc الذي تم إنشاؤه بواسطة tsickle في إخراج الوحدة النمطية es2015؟

kylecordes نعم ، أحصل على نفس الإخراج بالضبط الذي تحصل عليه في الريبو التجريبي الذي نشرته أعلاه مع تجميع ملف tsc و rxjs-tsickle tsconfig.

هل يمكننا نقل الأخطاء إلى مشكلة أخرى؟ لا يتسع نطاقه لمعالجة المشاكل الفردية في مسألة التتبع. شكرا!

تضمين التغريدة لقد نشرت هنا في البداية لأنني اعتقدت أن هذا كان ذا صلة (مشكلة في كيفية إعلان rxjs للحجج المسماة "هذه" التي ضاعت). لا يوجد شيء للمتابعة ، ولكن إذا حدث شيء ما ، فسنقوم بذلك في قضية منفصلة.

nosachamos في الواقع ... لقد وجدت للتو أنه في الواقع ، يمكن لـ tsickle-via-ngc أو -cli-wrapped التعامل مع module:es2015 .

alexeagle آه ، عفوًا. في أكثر من 90 تعليقًا ، لم أكن أدرك أنها كانت مشكلة تتبع. سوف تصدر قضايا جديدة إذا ظهرت.

ألق نظرة أخرى على الحزمة التي تم إنشاؤها. لاحظت أن هناك بالتأكيد مجالًا لمزيد من التخفيضات في الكود هنا.

ليس من السهل دائمًا على Closure التعرف على الكود غير الضروري لأن بنية الكود الحالية تجعل الأمر يبدو أحيانًا وكأن الكود مطلوب.

استنادًا إلى تطبيق POC في repoalexeagle ، اخترت بعض العناصر المضمنة غير الضرورية وقمت ببعض التعديلات المؤقتة على المصدر لإجبارهم على الخروج من الحزمة.

يبدو أن هناك بعض الأنماط المتكررة هنا:

قد لا يحتاج التطبيق إلى فئة الخدمة ، ولكن إذا تمت إضافة الخدمة إلى مصفوفة مزود على طول الطريق ، فقد يتسبب ذلك في جعل الفئة في الحزمة. ومن الأمثلة على ذلك AnimationDriver و AnimationQueue . من خلال إزالة مراجع الموفر إلى هذه الفئات ، يمكنني إخراج هذه الفئات من الحزمة.

لا يقوم التطبيق النموذجي في repo الخاص بـ Alex بأي استعلام عن قائمة QueryList ، ولكن لا يزال الكثير من التعليمات البرمجية المتعلقة بالاستعلام في الحزمة.
في هذه الحالة ، لا يمكن أن يستبعد الإغلاق الكود لأن الكود موجود في عبارة 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 أو أيًا كان ، فسيتم حذف عبارات الحالة المعينة هذه من الكود الذي تم إنشاؤه.

أفكار؟

بناءً على ما تعلمته من إزالة الكود يدويًا في الحزم ، قمت بتطبيق تعديلات مماثلة على الحزم في شوكة الإغلاق.

أضع التعديلات في فرع إذا كنت مهتمًا برؤية النتائج: 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 كيلو gzip ، وأصغر قليلاً مع 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 ، ولكن من المثير للاهتمام على الأقل معرفة مدى صغر حجم التطبيق الأساسي.

لست متأكدًا من مدى فائدة ذلك ، لكنها على الأقل تجربة ممتعة :-)

في تلخيص:
يتم توفير الكثير من التوفير من إزالة الكود من هياكل التبديل / if-else. لا يمكن أن يستنتج الإغلاق حاليًا أن بعض الخيارات غير ممكنة في وقت تشغيل تطبيق معين. حالة أخرى هي مصفوفات الموفر المليئة بالخدمات غير المستخدمة.

كما أفهم من عمل thelgevold ، هناك انخفاض كبير في حجم الإنتاج ، مع تعديل بسيط إلى متوسط ​​نسبيًا على Angular:

• استوعب عددًا أقل من الميزات باستخدام if والتبديل في الكود المصدري.
• الوصول المهيأ مسبقًا مرة أخرى إلى عدد أقل من هذه الميزات ، في مصفوفات الموفر المضمنة.
• اضبط المترجم (الذي يؤثر على كل من JIT و AOT) لإنشاء وحدات بت إضافية من التعليمات البرمجية لتوصيل هذه الميزات / الموفرين في الكود الذي تم إنشاؤه ... إذا تم استخدام الميزات بالفعل.

أنا مهتم بما يعتقده شخص ما في الفريق الأساسي عن هذا ، سواء كان الأمر بسيطًا إلى معتدل حقًا وما إذا كان هناك اهتمام بالسير في هذا المسار.

اليوم حصلنا على إصدار من rxjs يعمل مع مترجم الإغلاق ، وقمت بتحديث مثال الريبو
https://github.com/alexeagle/closure-compiler-angular-bundling

يتم تنظيف العناصر الخارجية أيضًا - يقوم كل من Angular و Zone.js بتوزيع العناصر الخارجية المطلوبة في عبواتهما الخاصة.
سنضيف بعض الوثائق والإعلان عن الدعم قريبًا.

الآن بعد أن أصبح كل هذا بعيدًا عن الطريق ، في هذه المرحلة ، هل لديك فكرة عن كيفية تكاملها مع بقية الأدوات الموجودة؟

على سبيل المثال ، هل يوجد في النهاية خيار مضاف إلى @ ngtools / webpack لتشغيل إخراج AOT تلقائيًا من خلال Closure (و / أو بعض خطوات التكوين الموثقة لـ webpack-close-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 Compiler حيث تضيع الطرق الثابتة ، لدينا أمر sed حقًا نقوم بتشغيله على ملفات Angular js المبنية ، مع استبدال جميع الأسطر التي تتضمن كلمة رئيسية ثابتة بالسطر الذي يسبقه / ** nocollapse * / . إليك رابط لخطأ Closure: google / clos-compiler # 1776

الزاوي

أكبر تغيير أجريناه على Angular هو جعله يستخدم مخرجات Tsickle المشروحة أثناء التجميع. اعتقدنا أننا فعلنا هذه المرة الأخيرة ، لكن كان لدينا خطأ حيث تم التخلص من الإخراج التوضيحي: D

كان هناك عدد قليل من الأماكن التي يشير إليها Angular الوظائف كسلاسل. تمت الإشارة إلى هذه الوظائف في أماكن أخرى باستخدام تدوين النقطة. وبناءً على ذلك ، تمت إعادة تسمية بعض المراجع بينما لم يتم تغيير أسماء أخرى. قمنا بتغيير Angular لاستخدام تدوين النقاط في كل مكان لهذه الوظائف ، بحيث يتم إعادة تسميتها دائمًا.

قمنا أيضًا بتحديث Angular / Tsickle لعدم إضافة تعليقات توضيحية لملفات d.ts.

لقد صنعنا لعبة Angular بشكل جيد مع ES6 ، لذا فهي تعمل في وضع غير مجمع. قمنا بتغيير بعض الأماكن حيث تم استخدام .apply على المُنشئ لاستخدام الكلمة الأساسية الجديدة.

تسيكل

لقد أصلحنا خطأ في tsickle حيث لم يتضمن CLI دائمًا جميع ملفات المصدر أثناء التعليق التوضيحي. يجب استخدام قائمة أسماء الملفات من برنامج 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
كلوتز: 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.

التغييرات التي أجريناها على التبعيات لجعل هذا يعمل إلى حد كبير هي نفسها تغييرات Alex. هناك بعض التغييرات التي أضفناها وبعض التغييرات التي لم تعد ضرورية. بغض النظر ، الفكرة الأساسية هي نفسها. نستخدم صيغة ngc أو tsickle معدلة على Angular 2 وتبعياتها لإنتاج إصدارات متوافقة مع Closure لتلك التبعيات.

مترجم الإغلاق

لم يعد البناء من الرأس ضروريا. ما عليك سوى استخدام أحد الإصدارات من يونيو أو يوليو.

الزاوي

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

الجزء الأكبر من العمل في Angular 2 source هو تعديل ngc لإنتاج Closure compilable js عن طريق إضافة بضع خطوات tsickle إلى tsc-ملفوفة. هناك عدد قليل من الأطواق التي ننتقل إليها من أجل استخدام المصدر المعدل كمدخل إلى مترجم 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 غير صالحة.

مرحبًا ، لقد قمت بتثبيت مشروعك ولكن متى حدث خطأ "إجراء التشغيل":
'tools/@angular/tsc-wrapped/src/compiler_host.ts (55،32): خطأ TS2345: الوسيطة من النوع' ts.Program 'غير قابلة للتخصيص إلى معلمة من النوع' ts.Program '.'
هل يمكنك مساعدتي؟

تم قفل هذه المشكلة تلقائيًا بسبب عدم النشاط.
يرجى تقديم مشكلة جديدة إذا كنت تواجه مشكلة مشابهة أو ذات صلة.

اقرأ المزيد عن سياسة قفل المحادثة التلقائي .

_{_تم تنفيذ هذا الإجراء تلقائيًا بواسطة روبوت ._}