Angular: تجميع Angular2 AOT - "لا يمكن تحديد الوحدة النمطية للفئة (... العديد من المكونات غير المستخدمة)"

لا يمكن تحديد الوحدة النمطية للفصل الدراسي

يجب أن يكون المكون جزءًا من وحدة نمطية. إنه مقصود.
أود أن أقول أنه طلب ميزة.

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

@ swimmadude66 يمكنك استبعاد الملفات غير المستخدمة في tsconfig

DzmitryShylovich يمكنك ذلك ، لكن ملفات البرميل تعقد ذلك. إذا تمت إعادة تصدير فئة في ملف برميل ، يجب أن أتجاهل ملف البرميل أيضًا ، مما قد يتسبب في مشاكل مع الفئات التي أحتاجها من هذا البرميل.

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

يبدو من الغريب أن المترجم يجب أن يحاول تجميع أكثر مما يجب عليه على الإطلاق.

هذه هي الطريقة التي يعمل بها المترجمون ...

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

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

يحاول زميلي في العمل إزالة أي ملفات برميل يمكن أن تمنعنا من استخدام استبعاد شامل ، لكني أطلب منك إلقاء نظرة على المشكلة التي فتحتها في الأصل ضد @ ngtools / webpack ، حيث تعرض مستخدم آخر لنفس الخطأ من مكون يشار إليه فقط في اختباراتهم. https://github.com/angular/angular-cli/issues/3636

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

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

Toxicable توجد الملفات غير المستخدمة في وحدة نمطية npm بنمط مكتبة. بشكل عام ، تكون حالة الاستخدام المثالية هي شيء من هذا القبيل:

في @ project / angular (وحدة npm للشفرة المشتركة) لدينا جميع المكونات والأنابيب والتوجيهات والخدمات اللازمة لإنشاء تطبيقنا الأساسي والتواصل مع نظامنا الأساسي الخلفي. يريد شركاؤنا تطبيقًا يبدو مشابهًا ، لكنه يستخدم صفحة رئيسية مختلفة ، أو يحتوي على بعض المكونات الجديدة المضافة. ومع ذلك ، ستكون معظم الصفحات الأخرى هي نفسها ، وقد تكون جميع الخدمات اللازمة للاتصال بمنصتنا هي نفسها.

كان نهجنا لتعظيم الكود القابل لإعادة الاستخدام هو جعل كل شريك يقوم بإنشاء وحدات ، واستيراد مجموعة من القطع الجديدة والقطع المشتركة من وحدة npm. قد يتم استيراد HomeModule الجديد الخاص بي مثل:

import {
    OverviewComponent,
    ProfileComponent
} from './components/home';

import {
    AuthComponent
} from '@project/angular';

هذا ثم ينفجر في AOT قائلا: Cannot determine the module for class OverviewComponent لأننا لا نستخدم OverviewComponent من @ project / angular.

نظرًا لعدم وجود ملفات تشير حرفيًا إلى @project/angular/components/home/overview/component.ts ، فلن أتوقع أن يهتم المترجم على الإطلاق بأنه غير مستخدم. ولكن نظرًا لوجود الملف داخل node_modules dir من مشروعنا ، فإن المترجم يجده ويشكو ويموت.

بالنسبة لأعمال JIT! == يعمل AOT ، يعمل التطبيق الأساسي مع AOT ، والتغييرات في شريك Proof of Concept صغيرة بشكل لا يصدق. لا أقصد الإيحاء بأن كل ما يعمل في JIT يجب أن يعمل في AOT ، لكن لدي سبب وجيه للغاية للاعتقاد بأن هذا يجب أن يعمل.

لدي مثال آخر حيث هذا السلوك الحالي لا معنى له - الاختبارات.
لنفترض أن لدي دليل ميزات some-feature ، بـ some-feature.component.ts و some-feature.component.spec.ts .
يستخدم هذا المكون عرض المحتوى ، لذلك أود اختبار هذه الوظيفة من خلال إنشاء مكون اختبار داخل ملف some-feature.component.spec.ts الخاص بي والذي يستخدم some-feature المكون في طريقة العرض ، مثل:

@Component({
  selector: 'test-app',
  template: `<some-feature><p>projected content</p></some-feature>`
})
export class TestAppComponent {}

ثم أستخدم هذا المكون في وحدة الاختبار الخاصة بي :

  ...
  beforeEach(() => {
    TestBed.configureTestingModule({
      declarations: [TestAppComponent, SomeFeatureComponent]
    })
  })
  ...

كل شيء صالح ورائع ، حتى عندما أقوم بتشغيل ng build --prod --aot باستخدام angular-cli ، والذي يرمي:
Cannot determine the module for class TestAppComponent .

لا أعتقد أن AOT يجب أن تهتم بملفات .spec ..

القاعدة العامة هي: سيقوم ngc بتجميع كل ما يُجمِّعه TS. وسيحاول تجميع كل مكون يجده. ومع ذلك ، لا يمكن لـ Angular تجميع المكونات بدون وحدة نمطية ذات صلة.

يمكننا تغيير هذا الخطأ إلى تحذير بالرغم من ذلك.

لدي أيضًا مكونات غلاف الاختبار المستخدمة للاختبار فقط والتي تتسبب في انفجار AOT كما هو موضح هنا. سيكون من الرائع أن تتجاهل AOT جميع المكونات التي ترضي تعبير حرف البدل مثل TestComponent * إلخ.

حسنا ، مزيد من المعلومات هنا. يبدو أننا وجدنا حلاً لحالتنا (لا يصلح حالة testWrapper). يبدو أن المشكلة الحقيقية في حالتنا كانت ملفاتنا البرميلية. عند استيراد أي شيء من ملف برميل ، فإنه يتبع سلسلة كل الأشياء التي يعاد إصدارها بواسطة البراميل. نظرًا لأننا كنا نسحب مكوناتنا من مستوى أعلى PROJECT/components ، فقد كان يتم تحليل جميع المكونات بدلاً من المكون الذي أردناه فقط. ربما لا يزال هذا أفضل كتحذير ، لكن يمكنني أن أفهم بشكل أفضل قليلاً سبب اهتمام المترجم بهذه المكونات.

رؤية نفس الخطأ:

$ ./node_modules/.bin/ng-xi18n
Error: Cannot determine the module for class DividerPanel in C:/msweb/studiotouch/src/comps/dividerpanel/DividerPanel.ts!
Cannot determine the module for class EntryPanel in C:/msweb/studiotouch/src/comps/entry/EntryPanel.ts!
Cannot determine the module for class ForgotPass in C:/msweb/studiotouch/src/comps/entry/ForgotPass.ts!
Cannot determine the module for class Footer in C:/msweb/studiotouch/src/comps/footer/Footer.ts!
Cannot determine the module for class Infobox in C:/msweb/studiotouch/src/comps/infobox/Infobox.ts!
Cannot determine the module for class InputNumeric in C:/msweb/studiotouch/src/comps/inputnumeric/InputNumeric.ts!
Cannot determine the module for class InputString in C:/msweb/studiotouch/src/comps/inputstring/InputString.ts!
Cannot determine the module for class Loading in C:/msweb/studiotouch/src/comps/loading/Loading.ts!
Cannot determine the module for class MapAddress in C:/msweb/studiotouch/src/comps/mapaddress/MapAddress.ts!
Cannot determine the module for class Minitab in C:/msweb/studiotouch/src/comps/minitabs/MiniTab.ts!
Cannot determine the module for class Minitabs in C:/msweb/studiotouch/src/comps/minitabs/MiniTabs.ts!
Cannot determine the module for class ModalDialog in C:/msweb/studiotouch/src/comps/modaldialog/ModalDialog.ts!
Cannot determine the module for class Ng2Highcharts in C:/msweb/studiotouch/src/comps/ng2-highcharts/src/directives/ng2-highcharts.ts!

Cannot determine the module for class Ng2Highstocks in C:/msweb/studiotouch/src/comps/ng2-highcharts/src/directives/ng2-highstocks.ts!

Cannot determine the module for class Ng2Highmaps in C:/msweb/studiotouch/src/comps/ng2-highcharts/src/directives/ng2-highmaps.ts!
Cannot determine the module for class simplelistEditable in C:/msweb/studiotouch/src/comps/simplelist/simplelistEditable.ts!
Cannot determine the module for class simplelist in C:/msweb/studiotouch/src/comps/simplelist/simplelist.ts!
Cannot determine the module for class FilterPipe in C:/msweb/studiotouch/src/pipes/FilterPipe.ts!
Cannot determine the module for class FilterPipeEqual in C:/msweb/studiotouch/src/pipes/FilterPipeNot.ts!
Cannot determine the module for class OrderBy in C:/msweb/studiotouch/src/pipes/OrderBy.ts!
Cannot determine the module for class ReplacePipe in C:/msweb/studiotouch/src/pipes/ReplacePipe.ts!
Cannot determine the module for class SortBy in C:/msweb/studiotouch/src/pipes/SortBy.ts!
    at analyzeAndValidateNgModules (C:\msweb\studiotouch\node_modules\@angular\compiler\bundles\compiler.umd.js:24878:17)
    at Extractor.extract (C:\msweb\studiotouch\node_modules\@angular\compiler\bundles\compiler.umd.js:27727:20)
    at Extractor.extractBundle (C:\msweb\studiotouch\node_modules\@angular\compiler-cli\src\extractor.js:40:33)
    at Extractor.extract (C:\msweb\studiotouch\node_modules\@angular\compiler-cli\src\extractor.js:30:34)
    at extract (C:\msweb\studiotouch\node_modules\@angular\compiler-cli\src\extract_i18n.js:7:67)
    at Object.main (C:\msweb\studiotouch\node_modules\@angular\tsc-wrapped\src\main.js:47:16)
    at Object.<anonymous> (C:\msweb\studiotouch\node_modules\@angular\compiler-cli\src\extract_i18n.js:14:9)
    at Module._compile (module.js:556:32)
    at Object.Module._extensions..js (module.js:565:10)
    at Module.load (module.js:473:32)
Extraction failed

root@DESKTOP-VEUHFOL /cygdrive/c/msweb/studiotouch

الزاوي 2 حوض المطبخ: http://ng2.javascriptninja.io
والمصدر @ https://github.com/born2net/Angular-kitchen-sink
يعتبر،

شون

يجب ألا تتبع i18 هيكل المشروع بالكامل وأن تنظر بدلاً من ذلك إلى الإعلانات المستخدمة.

حاولت تنظيف التعليمات التي لم يتم استخدامها ، وتعمق حفرة الأرانب للتو:

$ ./node_modules/.bin/ng-xi18n
Error: Error at C:/msweb/ng-skeleton/node_modules/typescript/lib/lib.d.ts:18770:11: Duplicate identifier 'ActiveXObject'.
Error at C:/msweb/ng-skeleton/node_modules/typescript/lib/lib.d.ts:18773:13: Duplicate identifier 'ActiveXObject'.
Error at C:/msweb/ng-skeleton/e2e/app.po.ts:1:38: Cannot find module 'protractor'.
Error at C:/msweb/ng-skeleton/node_modules/@angular/core/src/facade/lang.d.ts:12:17: Cannot find name 'Map'.
Error at C:/msweb/ng-skeleton/node_modules/@angular/core/src/facade/lang.d.ts:13:17: Cannot find name 'Set'.
Error at C:/msweb/ng-skeleton/node_modules/@angular/core/src/application_init.d.ts:16:18: Cannot find name 'Promise'.
Error at C:/msweb/ng-skeleton/node_modules/rxjs/Observable.d.ts:68:60: Cannot find name 'Promise'.
Error at C:/msweb/ng-skeleton/node_modules/rxjs/Observable.d.ts:68:70: Cannot find name 'Promise'.
Error at C:/msweb/ng-skeleton/node_modules/@angular/core/src/linker/compiler.d.ts:53:49: Cannot find name 'Promise'.
Error at C:/msweb/ng-skeleton/node_modules/@angular/core/src/linker/compiler.d.ts:61:65: Cannot find name 'Promise'.
Error at C:/msweb/ng-skeleton/node_modules/@angular/core/src/application_ref.d.ts:116:67: Cannot find name 'Promise'.
Error at C:/msweb/ng-skeleton/node_modules/@angular/core/src/application_ref.d.ts:132:101: Cannot find name 'Promise'.
Error at C:/msweb/ng-skeleton/node_modules/@angular/core/src/application_ref.d.ts:158:67: Cannot find name 'Promise'.
Error at C:/msweb/ng-skeleton/node_modules/@angular/core/src/application_ref.d.ts:160:101: Cannot find name 'Promise'.

اسمحوا لي أن أضيف أن كل شيء يعمل بشكل جيد مع angular-cli و angular-compiler ، لذا فإن i18 فقط لا يحب مشروعي.

المرجع (إعداد جميل ونظيف): https://github.com/born2net/ng-skeleton

يعتبر،

شون

نفس الخطأ بالنسبة للمكونات التي تم التعليق عليها .. المكونات غير المستخدمة والتي تم التعليق عليها لمرحلة التطوير هي مجرد خطوة مفيدة لعدم المعالجة

// two comments aot read:

//  {path: 'about', component: AboutComponent 
// import { AboutComponent } from './about';

يجمع kirjai ngc جميع الملفات داخل دليل المصدر. لا يهم إذا كنت تقوم باستيراده أم لا.

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

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

لقد واجهت أيضًا رسالة الخطأ هذه (وبعضها الآخر) بسبب رمز الاختبار و AOT معًا.

يمكنني أن أوصي بهذا المقال . يشرح كيف يمكن استفزاز رسائل خطأ معينة وكيفية إصلاحها / حلها.

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

(إذا بحث شخص ما عن إجابة بخصوص RouterLinkStubDirective )
_يمكنك إصلاحه عن طريق إضافة وحدة "وهمية": _

/**
 * Needed so that `aot` build is working. But it isn't used throughout our tests and/or app.
 */
@NgModule({
    imports: [
        AppModule
    ],
    declarations: [
        RouterLinkStubDirective,
        RouterOutletStubComponent
    ]
})
export class FakeRouterModule {
}

بالمناسبة ، يحاول أيضًا تحديد الوحدة النمطية للفئات المجردة:
export abstract class AsyncTransform extends AsyncPipe implements PipeTransform { ... }

"خطأ: لا يمكن تحديد الوحدة النمطية للفئة AsyncTransform"

إضافته إلى وحدة نمطية أيضًا لا تعمل 😄.
"لا يمكن تعيين نوع مُنشئ مجرد لنوع مُنشئ غير مجردة."

هذا ما يحدث لبعض الفصول أيضًا.

خطأ: لا يمكن تحديد الوحدة النمطية للفئة AppGlobalModalComponent

export class CustomGlobalModalComponent extends AppGlobalModalComponent {}

gestj كما أشار Phmager ، الوحدات الوهمية ليست حلاً لجميع الحالات. بالإضافة إلى ذلك ، فهي حل رائع جدًا ، حيث ينتهي بك الأمر إلى تجميع التعليمات البرمجية التي لا تريدها أو تحتاجها.

بالنسبة لحالتنا ، قمنا بتصحيح المشكلة بطريقة مختلفة. نقلنا مكوناتنا المشتركة إلى npm lib ، وتجاهلنا node_modules في tsConfig الخاص بنا. لقد ذكرت أعلاه أنه لا يزال لا يعمل ، ولكن فقط لأننا كنا نستخدم ملفات برميل. إذا كنت تشير مباشرة إلى كل فئة تحتاجها داخل node_modules ، فسوف تتجاهل الفئات الأخرى. ومع ذلك ، بمجرد أن تشير إلى برميل ، فإنه يلقي الخطأ للملفات غير المستخدمة في نفس البرميل.

هذا ليس مثاليًا ، لأنه يقتل جميع ملفات البراميل الرائعة ، ولكن على الأقل يمكن التنبؤ بها.

ما زلت آمل أن يتم تخفيض هذا الخطأ إلى تحذير

عمل رائع تم إنجازه في فريق Angular حتى الآن.
نحن نستخدم Angular بشكل كبير في مشاريعنا وبعد عام واحد من محاولة فهم كل هذه الأشياء Angular2 + الصاخبة ، إليك ما توصلت إليه:
1- الزاوي ضخم وبطيء ، هل تريد أن تجعله سريعًا؟ استخدم AOT و LazyLoading و gzip عناصرك.
2- هل تريد lazyLoad مكون؟ لا ، ستكون قادرًا على تحميل مسار واحد كسول ، لذلك إذا كان التطبيق ضخمًا ولكن صفحة واحدة فقط ، فاستمتع بحجم حزمة 8 ملليجرام.
3- هل تريد استخدام AOT ؟؟ AOT عبارة عن عربات التي تجرها الدواب ويصعب الامتثال لها ولا تستخدم أكوامًا من ميزات جافا سكريبت / es6 وربما تعيد كتابة الكثير من التعليمات البرمجية الخاصة بك.
4- أنت تستخدم AOT بخير؟ حسنًا ، ألقِ نظرة الآن على الحزمة النهائية الخاصة بك ، فهي الآن أكبر من @ angular / compiler بالإضافة إلى مكوناتك التي لم يتم تشغيلها AOTed ، أحسنت.

5-كجزء من ميزة Angular2 + ، فأنت الآن مؤهل لاستخدام gzip ، فقط في حال لم تكن تعرف كيفية استخدامه من قبل ، والآن بعد أن أصبح Angular ضخمًا ، ستتعلمه بشكل أفضل :) نبيع gziping كخيار لتحسين كود Angular2 :)

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

build: dev في https://github.com/AngularClass/angular2-webpack-starter auto يحول سلسلة إلى مصفوفة سلسلة لمطابقة تعريف دالة ، الإنشاء: aot يظهر الخطأ. أثناء التطوير ، يبدو أن عمليات إنشاء AOT المتكررة ضرورية.

لدي نفس المشكلة ، ووجدت حلاً ، ربما يعمل أيضًا بواسطتك.

كان السيناريو الخاص بي كالتالي:

لدي MapPipes.ts ، يحتوي على اثنين من الأنابيب.

تم استخدام أحد الأنابيب في وحدتي ، والآخر لم يتم استخدامه. وبالتالي ، لم أسجل الثانية في "الإعلان:" جزء من مصمم NgModule الخاص بي. حدثت المشكلة لهذه الثانية.

لقد سجلت هذا أيضًا (على الرغم من عدم استخدامه) ، وهو يعمل الآن.

اقتراحي هو تغيير المترجم الزاوي بطريقة تحاول العثور على وحدات فقط للكيانات الزاوية المستخدمة بالفعل.

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

DzmitryShylovichkirjai هذه مشكلة فقط مع TestComponents في ملف المواصفات إذا قمت بتصديرها. وبما أنه يجب استخدامها فقط في نفس الملف فلا داعي لتصديرها. حلت المشكلة بالنسبة لي.

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

cwmrowe لا بأس بذلك ، ولكن ماذا لو كان لديك ملف يُعاد استخدامه في ملفات مواصفات متعددة؟ يبدو أن هذا كسر حتى نكون صادقين.

في حالتي ، كنت أعمل على مشروعين مختلفين في نفس تطبيق Angular 2 الأساسي. لدي مجلدين تم تسميتهما باسم عملائنا ، على سبيل المثال some-domain.com و some-other-domain.com . التطبيق هو نفسه تمامًا للمشروعين ويختلف فقط في القليل من التصميم وبعض المكونات المخصصة الثانوية. أحتاج اليوم إلى تجميع التطبيق للعميل A ، وأريد لاحقًا تجميع التطبيق للعميل B. في الكود ، يكون الأمر سهلاً مثل تغيير سطر واحد من التعليمات البرمجية بالنسبة لي:

import {CustomModules} from './some-domain.com';
// import {CustomModules} from './some-other-domain.com';

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

لدينا نفس المشكلة مع فئات الوراثة والمجردة ولم نجد أي حل. لدينا بعض المكونات التي توسع مكونًا مجردًا. في JIT ، كل شيء يعمل بشكل رائع ولكن في AOT لا يمكن العثور على الوحدات النمطية للمكونات المجردة ولا يمكن إعلان المكونات المجردة في وحدة نمطية.

ليس لدينا حاليًا أي حل بخلاف تجنب أنماط تصميم oop واستخدام التعليمات البرمجية الزائدة عن الحاجة.

jabaa قم بإزالة التعليق التوضيحي @Component من فصل الملخص

DzmitryShylovich عندما أقوم بإزالة @Component ، لا يتم توريث المُنشئ. لا بد لي من حقن جميع المواد القابلة للحقن في جميع المكونات بدلاً من المكون المجرد. هذا رمز فائض عن الحاجة. عندما أقوم بتغيير المُنشئ وخدمات الفصل المجرد ، يجب أن أتقن جميع المكونات الفرعية.

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

jabaa ما هو الإصدار الذي تستخدمه؟ يجب أن يتم توريث المُنشئ بغض النظر عن @Component .

bigjetplane لست متأكدًا من مكان المشكلة ، ولكن عندما أزيل @Component يظهر لي خطأ يفيد بأنه تعذر العثور على تبعيات المكون. بقدر ما أعرف ، تعمل DI فقط في الفصول ذات الديكور الزاوي. لذلك عندما أزيل الديكور ، لا يتم حقن التبعيات. نستخدم Angular 4.

jabaa هل انكسرت جيت أم آوت أم كلاهما؟

bigjetplane هنا هو الغطاس مع المشكلة. هناك فصل دراسي مع مصمم الديكور وكل شيء يعمل بشكل جيد. عندما تزيل المصمم من فئة abstract ، لا يمكن عرض التطبيق لأنه لا يمكن تحميل جميع التبعيات: Can't resolve all parameters for App: (?).

هذه حالة استخدامنا. لدينا فئة مجردة مع منشئ وحقن. نريد فقط تجاوز بعض الأساليب المجردة في المكونات الفرعية

المثال المعطى لا يعمل في aot. الفرق بين aot و jit مشكلة كبيرة بالنسبة لنا. نحن نطور مع جيت. بناء الإنتاج مع aot. لذلك نحن نعمل على تطوير أسبوع مع jit دون أخطاء وتحذيرات وبعد الأسبوع نريد إنشاء إنتاج والحصول على العديد من الأخطاء من أي مكان. أفضل مفتاحًا لـ jit ، حيث يمكنني تمكين أخطاء aot. يحتاج بناء jit من 10 إلى 20 ثانية. يحتاج بناء aot إلى 25 دقيقة.

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

شكرا!

أنا أيضا لدي نفس المشكلة.

في حالتي ، كنت أعمل على مشروعين مختلفين ولكن تم تضمين المكونات المشتركة من خلال مشروع مكتبة زاوية داخلية مضافًا كتبعية في package.json.

نظرًا لأنه مشروع مكتبة ، فإن المكونات غير المستخدمة من مستودع المكونات تلقي بالخطأ أدناه عند تجميع بناء AOT prod.

ERROR in Cannot determine the module for class FullPageErrorComponent in C:/users/amra6003/projects/git/refadmintoolui/n ode_modules/refcommonui/src/app/component-library/error/error.component.ts! Cannot determine the module for class SelectCountryComponent in C:/users/amra6003/projects/git/refadmintoolui/node_modul es/refcommonui/src/app/component-library/select-country/select-country.component.ts! Cannot determine the module for class DateRangeSelectorComponent in C:/users/amra6003/projects/git/refadmintoolui/node_m odules/refcommonui/src/app/component-library/date-range-selector/date-range-selector.component.ts!

يبدو أنه يتعين علي إنشاء وحدة نمطية لكل مكون والاستخدام:

أي إصلاح لهذه المشكلة سيساعد كثيرًا.

أنا أيضا آمل في إصلاح هذا. يبدو أن استخدام مكونات كعب الروتين للاختبار مقصود من قبل مطوري Angular - لذا يجب أيضًا أن يكون استبعادهم من البناء بطريقة نظيفة أمرًا ممكنًا. في الوقت الحالي ، أستخدم الحل البديل الذي اقترحه Gestj (تحديد وحدة نمطية مزيفة يتم فيها الإعلان عن المكون الجذري).

لذلك ، عند استخدام مكونات stub للاختبار ، فأنت تريد تسمية المكون الخاص بك باستخدام sufix spec.ts مثل whatever.component.spec.ts . بهذه الطريقة سوف يتجاهل tsc هذه الملفات (نظرًا لاستبعادها في tsconfig الخاص بك) وبالتالي سيتم تجاهلها بواسطة ngc أيضًا.

تحرير: اتضح أن هذا خطأ مختلف ، ناتج عن خطأ في ngtools / webpack. تم فتح تلك التذكرة هنا: https://github.com/angular/angular-cli/issues/6228

متعة جديدة على هذه الجبهة لشركتي. في محاولة أخيرة لترقية أنظمتنا إلى الإصدار 2.4.10 ، انتهى بي الأمر بوقتي ببضع عشرات من الأخطاء من هذا التنوع:

ModuleNotFoundError: Module not found: Error: Can't resolve '../../../../../../../../$_gendir/src/components/spinner/component.ngfactory'

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

لست متأكدًا مما يمكننا فعله حيال هذا بالرغم من ذلك. لقد حاولنا معالجة كل مكون نحتاجه من lib المشترك مباشرةً (بدون استخدام أي ملفات index.ts ، حيث يبدو أن تلك الملفات تسحب كل ملف مشار إليه في الفهرس) ونقل كل lib المشترك إلى node_modules.

لماذا يحتاج المحول البرمجي إلى معرفة كل مكون زاوية في مجلد node_modules ؟ حتى لو احتاج إلى قراءتها لبناء خريطتها ، فلا ينبغي أن يهتم بما إذا كان لديهم وحدة نمطية أم لا!

@ swimadude66 ، نعم واجهنا هذا العمل مع مكتبة https://github.com/WealthBar/a2d3 . على الرغم من أنه لا يوفر مكونات نموذجية (توجيهات فقط) ، لا يزال يتعين إنشاء المكتبة باستخدام مترجم AoT وإلا فلن تعمل مع تصميمات AoT عند استخدامها.

chrisnicola أنت تقول أن المكتبة يجب أن يتم تجميعها مسبقًا باستخدام AoT قبل نشرها؟ لأن هذا يعني أن للمكتبة وحداتها الخاصة ، والتي تبدو غير بديهية حقًا. كما هي ، المكتبة عبارة عن ملفات ts غير مجمعة ، والتي نسحبها تمامًا مثل أي ملف آخر في مشروعنا. ثم يتم تجميع كل شيء باستخدام المكون الإضافي @ ngtools / webpack إلى webpack.

من الجدير بالذكر أنه حتى الخطأ الأصلي لهذه التذكرة تم "إصلاحه" من جانبنا حتى الإصدار 2.1.1 عن طريق إزالة جميع الإشارات إلى ملفات index.ts. يبدو أن هذا الإصلاح لم يعد يعمل مع الإصدار 2.4.10.

آه فهمت ، نعم أخطأت في قراءة مشكلتك. أنت لا تسحب مكتبة مشتركة مجمعة مسبقًا عبر NPM هنا ، لديك مكتبة TS محلية في مشروعك. هل فهمت بشكل صحيح الآن؟

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

لقد تمكنت من حل جميع مشاكلنا المتعلقة بهذا الخطأ.
تظهر المشكلة (والحل) عند التصدير.

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

لحلها ، أعلنا للتو عن وحدة (تأكد من تصديرها أيضًا):

@NgModule({ declarations: [MyUnusedComponent] })
export class IgnoreModule {}

كان المكون الآخر الذي تسبب في حدوث خطأ هو مكون غير مستخدم اخترق i18n.
كان يتم تصديره ليتم التقاطه بواسطة أداة i18n ولكن هذا تسبب في نفس الخطأ مثل المكون الآخر.

@Component({
    template: `
        <div i18n="some context@<strong i="13">@some</strong> key">some text to be translated</div>
    `
})
export class LocalisationComponent {}

مرة أخرى باستخدام تقنية IgnoreModule يمكننا تجاوزها بسهولة.

@NgModule({ declarations: [LocalisationComponent] })
export class IgnoreModule {}

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

Phmager هل سبق لك العثور على حل لمشكلة المكون المجرد؟ أنا سحب شعري.

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

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

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

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

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

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

بصراحة بعد 5 أشهر من مشاهدة هذه التذكرة لا تذهب إلى أي مكان ، نحن نبحث في خيارات أخرى ، بما في ذلك مجرد قتل رمز إعادة الشراء المشترك الخاص بنا

أواجه نفس المشكلة التي تواجهها بالضبط ، @ swimmadude66 . حقيقة أن هذا ليس تحذيرًا قابلاً للقمع أمر مثير للسخرية.

عزيزي فريق Angular ، هل هناك أي شيء يمكنك القيام به حيال ذلك؟

DzmitryShylovich كيف يمكنني استبعاد ملف mock.ts لا أستخدمه؟ حاولت وضعه في tsconfig.app.json و tsconfig.json و tsconfig.ng-cli.json ويبدو أن لا شيء يعمل.

نواجه نفس المشكلة مع نفس حالة الاستخدام بالضبط - نستخدم Rollup ، لذلك لا تصل المكونات غير المستخدمة إلى الحزمة النهائية.

الرجاء قمع هذا! إنه مصدر إزعاج كبير ويوقف العمل.

لقد واجهت هذا أيضًا ، محبط للغاية.

mlakmal وآخرون ، الذين حصلوا على خطأ في التعليمات البرمجية مثل

export class CustomGlobalModalComponent extends AppGlobalModalComponent {}

قم بإزالة التعليق التوضيحي @Component من AppGlobalModalComponent أو قم بالإعلان عن AppGlobalModalComponent (إذا كان قابلاً للاستخدام) في NgModule

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

أتساءل عما إذا كانت العلامة "freq1: low" بشأن هذه المشكلة ترجع إلى حقيقة أن AoT يمثل ألمًا مذهلاً في المؤخرة لبدء العمل ، لدرجة أن الناس لا يزعجهم ذلك؟ إنه أمر لا يمكن تصديقه إلى حد ما أن مثل هذه المشكلة البسيطة ولكنها مؤلمة لم تتلق أي ردود فعل من المساهمين الأساسيين في Angular.

على أي حال ، هناك طريقة لاستبعاد الملفات التي لم يتم ذكرها على وجه التحديد. إذا كان لديك نمط تسمية (على سبيل المثال ، .spec.ts ، .abstract.ts ، .stfu-aot.ts ) ، يمكنك إنشاء ملف tsconfig.json منفصل لـ AoT واستخدامه بدلاً من ذلك: ngc -p tsconfig-aot.json . في هذا الملف يمكنك استخدام "exclude": ["./app/**/*.stfu-aot.ts"] لاستبعاد الملفات. إنه أمر مزعج ، لكن يجب أن يعمل.

تحرير: لا يبدو أن ما ورد أعلاه يعمل مع فئات abstract التي ترث من أحد المكونات. ياي :(

لقد واجهت هذا أيضًا ، لذلك أمر محبط للغاية. عند إنشاء aot ، لا يمكن مشاركة مكون مشترك في تطبيق آخر

في بعض الحالات الشائعة لهذه المشكلة ، تجنب إضافة Component إلى فئة الخدمات الخاصة بك:

// just remove this 
@Component({
    providers: []
});
@Injectable()
export class serviceClass {}

لدي سيناريو حيث أقوم بحقن خدمة في إحدى الخدمات. للوهلة الأولى ، يبدو أنه أمر سهل التنفيذ ، فقط أضفComponent. لذلك يجب تحديث مستندات Angular لإظهار هذا الحل للخدمات المعقدة: لحل هذه المشكلة ، قمت بإزالةComponent. أضفت في مُنشئ الخدمة:
constructor(@Inject(ExampleService) private exampleService: ExampleService)

لست بحاجة إلى إضافة مصمم الديكور @Component() إلى أي خدمة. فقط @Injectable()

FWIW لديّ MockXYZComponent يمتد XYZComponent أحد مكونات التطبيق ولكنه يُستخدم فقط في المواصفات (له نفس المحدد وبالتالي لا يمكن استيراده إلى AppModule ).

أليست هذه حالة استخدام صالحة؟

@ alastair-todd لست متأكدًا من أنني أفهم ماذا تقصد. إذا كنت تستخدم المكون كمكون ثم أضف @Component() decorator. إذا كنت تستخدم المكون كقاعدة - فقط لترث منه ، ولكن ليس كمكون ، فلن تضطر إلى استخدام الزخرفة - ولكن فقط ترث وتستخدم الزخرفة على "الوريث".
حول اختبار الوحدة - لا يمكنني الاستجابة ، ربما تحتاج إلى إنشاء وحدة اختبار خاصة؟ لا أقوم باختبار الوحدة في الوقت الحالي.

tytskyi فهمت لم يتم دعم وراثة الديكور. هل تغير ذلك مؤخرًا؟

حالة الاستخدام هي السخرية من مكون فرعي على النحو التالي. كلاهما يحتاج إلى التوجيه Component لالتقاط المحدد.

    beforeEach(() => {
        TestBed.configureTestingModule({
            imports: [
                AppModule
            ]
        }).overrideModule(AppModule, {
            remove: {
                declarations: [SelectionToolComponent]
            },
            add: {
                declarations: [MockSelectionToolComponent]
            }
        }).compileComponents();

ومع ذلك ، فإن هذا يولد خطأ تجميع OP AOT.

وجهة نظري هذه حالة استخدام صالحة ، وفي هذه الحالة يكون تجميع AOT مفرط الحماس و / أو يتجاهل المواصفات كجزء من المشروع.

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

أود أن أسمع عن أي حل أفضل.

هذا غريب ومحرج لدرجة أن هذه المشكلة تم فتحها في ديسمبر 2016 وما زالت بها هذه المشكلة. لقد قمت بتحويل هيكل تطبيقي بالكامل لاستخدام تجميع aot. لدي 4 وحدات محملة كسولًا وأكثر من 60 مكونًا. يشكو المترجم فقط من مكونين فقط (وفقًا لما يوحي به الخطأ) وأنا متأكد من أنهما بالفعل جزء من إعلانات إحدى الوحدات النمطية المحملة الكسولة والتي هي نوعًا ما غريب بالنسبة لي.

حتى أنه يعطي أخطاء في المكونات التي هي بالفعل جزء من وحدة ما.

المشكلة نفسها

يبحث مترجم Angular في مجموعة الملفات التي سلمتها إلى tsconfig - لذا فإن استبعاد الملفات من هناك يجب أن يستبعدها من هذا الفحص.

هذا أمر مزعج حقًا :(

@ alastair-todd آسف ، لقد فقدت إخطارك بسؤالك في الكثير من الإخطارات الأخرى. انت على حق -
وراثة الزخرفة غير معتمدة.

انظر الإجابة من robwormald

يبحث مترجم Angular في مجموعة الملفات التي سلمتها إلى tsconfig - لذا فإن استبعاد الملفات من هناك يجب أن يستبعدها من هذا الفحص.

لذا يمكنك محاولة عمل اصطلاحات لأسماء الملفات الوهمية ، مثل: selection-tool.component.mock.ts . ثم استبعد عبر

"exclude": [
    //... other excludes
    "**/*.component.mock.ts"
]

نقرت بالخطأ على الزر الخطأ ، آسف!

+8 أشهر وما زالت مشكلة. نفس المشكلة هنا ERROR in Cannot determine the module for class PasoFooterComponent

أعتقد أنه من الضروري لمطوري Angular تجاهل هذه الملفات.

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

إذا كان أي شخص يعتقد أن هذه ميزة وليست خطأ ، فماذا عن لدينا علم
لهذا؟

يوم الأربعاء ، 9 أغسطس 2017 ، الساعة 2:40 صباحًا ، ليوناردو فيدال [email protected]
كتب:

+8 أشهر وما زالت مشكلة. نفس المشكلة هنا ERROR في Cannot
تحديد الوحدة النمطية لفئة PasoFooterComponent

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

samirotiv هل لديك أي استنساخ؟
كما قال robwormald

يبحث مترجم Angular في مجموعة الملفات التي سلمتها إلى tsconfig - لذا فإن استبعاد الملفات من هناك يجب أن يستبعدها من هذا الفحص.

واجهت نفس المشكلة لكنني تمكنت من حلها. لقد نظرت للتو في كيفية تحويل تطبيقي على سبيل المثال

"tsc": "rimraf out-tsc/app && tsc -p ./src/tsconfig.app.json",

ولاحظت أن الكتابة المطبوعة لم تجمع الوحدات التي تم تحميلها بطيئًا لأنني استخدمت خيار tsconfig "الملفات"

أتلقى هذا الخطأ في فصل دراسي مجردة (بدون أدوات تزيين)

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

+1 لتغيير الخطأ إلى تحذير.

يبدو وكأنه حل سهل. لماذا التأخير؟

هذا مطلب أساسي - اترك ملفات غير مرجعية.
هذا القيد مشكلة للمشاريع الكبيرة. الرجاء تغيير هذا إلى تحذير.

هناك حالات عندما تقوم بنشر حزمة تدعم إصدارات مختلفة من الزاوية. ومن المتوقع أن يختار المستخدم أحدهما.

على سبيل المثال ، الحزمة التي توفر ملفات لكل من HttpClient (Angular> = 4.3 مستخدمين) و Http (Angular <4.3 من المستخدمين)

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

ما فعلته كان هذا:

لقد قمت بحفظ جميع مكونات stub / mock بامتداد .mock.ts وقمت بتحديث مصفوفة "استبعاد" tsconfig.app.json مثل:

...
  "exclude": [
    "test.ts",
    "**/*.spec.ts",
    "**/*.mock.ts"
  ]
...

يتخطى AOT الآن تجميع هذه الملفات

نحن نقوم بإنشاء مكتبة npm بمكونات مشتركة من المفترض ألا يتم استخدامها كلها مرة واحدة ومثيرة للغضب بسبب هذه المشكلة أثناء تجميع AoT ، اللعنة ... الحل الوحيد للصراف الآلي هو إنشاء نوع من UnusedComponentsModule في مشروع مضيف - أمر مثير للسخرية! تحتاج أيضًا إلى NO_ERRORS_SCHEMA أو ستقسم حول المكونات الأخرى التي يمكن استخدامها داخل المكونات غير المستخدمة ، وإذا كنت ستعلن عنها ، فستواجه مشكلة أخرى حيث لا يمكنك التصريح عن نفس المكون في وحدتين (تتعلقان بـ # 10646).

وحدتي الحالية:

import {NgModule, NO_ERRORS_SCHEMA} from '@angular/core';
import {CommonModule} from '@angular/common';
import {ReceiverPageComponent} from 'cb-web-platform';

@NgModule({
  imports: [
    CommonModule,
  ],
  declarations: [
    ReceiverPageComponent
  ],
  schemas: [
    NO_ERRORS_SCHEMA // IMPORTANT: need that for AoT compilation
  ]
})
export class UnusedComponentsModule {
}

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

يكون الأمر سهلاً عندما يكون رمزك. عندما تكون هناك مشكلة في بعض مكتبة NPM الزاوية (بعض الرموز الميتة) ، فهذا أمر مؤلم حقًا :)

هل يمكن لأي شخص أن يشرح لماذا لا يمكن أن يكون تحذيرًا بدلاً من خطأ؟

في حالتي ، أريد فقط استخراج اللغات بشكل مفضل من المكونات المتصلة بـ ngModule وتجاهل أولئك الذين ليسوا كذلك. لدي مجلد تطبيق رئيسي واحد يحتوي على مكونات أساسية ومجلدات خاصة بالتطبيق والتي تتجاوز أحيانًا المكونات من التطبيق الرئيسي عندما أحاول استخراج هذا المكون الذي تم تجاوزه باستخدام xi18n ، فإنه يلقي بخطأ Cannot determine the module for class... والذي في رأيي يمكن فقط تجاهله واستخراجه يمكن أن تستمر دون استخدام هذا المكون غير المستخدم.

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

Xesenix على الأقل يجب أن يكون خيارًا. مثل selectModule = false / true. الآن إنه الموز.

سأعود بتاريخ 11/1/2017.

سأرد على رسالتك بعد عودتي.
في الحالات العاجلة ، يرجى إرسال نسخة من بريدك الإلكتروني لـ
المسائل التقنية إلى [email protected] ، وإلا
[email protected]. سيقوم موظف آخر بعد ذلك بإلقاء نظرة على بريدك الإلكتروني
قبول.

ملاحظة: هذا رد تلقائي على "Re:
[الزاوية / الزاوية] تجميع Angular2 AOT - "لا يمكن تحديد الوحدة
للفئة (... العديد من المكونات غير المستخدمة) تم إرسال "(13590 # #)"
23/10/2017 08:13:17.

هذا هو الإشعار الوحيد الذي ستتلقاه أثناء
هذا الشخص غائب.

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

شكرًا لك @ rahul-sivalenka-wtc على الحل!
لقد نجحت في حل مشكلتي باستبعاد "**/*.mock.ts" في tsconfig.app.json كما تصف ❤️

سعيد لأنني استطعت المساعدة 😊

لقد قابلت المشكلة أيضًا. لكن بالنسبة لي يبدو أنني أخطأت في طريق استيراد الدودول

اي حلول؟ (لا يمكن تحديد الوحدة النمطية للزاوية المكون 5)

https://stackoverflow.com/questions/47119135/cannot-determine-the-module-for-component-angular-5

يجب أن يكون هذا على الأرجح بمقدار severity3: broken . بالنسبة لأولئك منا الذين لديهم أهداف بناء متعددة وتبعيات متعددة الأشكال (العديد من حالات الاستخدام التي كانت موجودة أعلاه) ، تمنع هذه المشكلة البنيات من العمل بدون إعداد مبني معقد مجنون.

أي حل جيد لهذه المشكلة حتى الآن؟ IgnoreModule هو مجرد حل بديل ولكنه ليس حلاً جيدًا لهذه المشكلة. سيكون تغيير الخطأ إلى تحذير أمرًا رائعًا!

كان الحل الذي قدمناه هو إضافة دالة transform إلى @ngtools/webpack لتمرير الملفات من خلال المعالجة المسبقة ، ومكونات ifdef ing بناءً على إعدادات وقت الترجمة المختلفة. قبيح جدا جدا ، لكن وظيفي.

حاول استيراد جميع التبعيات الزاوية أولاً في app.module.ts ثم قم باستيراد المكونات.

"---------------- أول وحدات تبعية الاستيراد -----------------------
استيراد {BrowserModule} من "@ angular / platform-browser" ؛
استيراد {CommonModule} من "@ angular / common" ؛
استيراد {NgModule} من "@ angular / core" ؛
استيراد {RouterModule، Routes} من "@ angular / router" ؛
استيراد {HttpModule} من "@ angular / http" ؛
استيراد {ReactiveFormsModule} من "@ angular / Forms" ؛
استيراد {BrowserAnimationsModule} من "@ angular / platform-browser / animations" ؛

------------- ثم قم باستيراد وحدات الخدمة ------------------------

استيراد {ApplyFormPostService} من './Services/apply-form-post.service' ؛
استيراد {NavBarColorService} من './Services/nav-bar-color.service' ؛

----------------------- أخيرًا قم باستيراد الوحدات النمطية للمكونات ----------------------- -

استيراد {AppComponent} من "./app.component" ؛
استيراد {HeaderComponent} من "./components/header/header.component" ؛
استيراد {CareerComponent} من "./components/career/career.component" ؛
استيراد {HomeComponent} من './Components/home/home.component' ؛ `

بطريقة ما أدى هذا إلى حل خطأ تجميع AOT لا يمكن تحديد الوحدة النمطية للفئة --- في وضع الإنتاج

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

يجب أن يكون تغييرًا بسيطًا بالفعل لجعل هذا الخطأ في تحذير ، ولكن لسبب ما استغرق الأمر أكثر من عام وتم نقله مؤخرًا من pri_col1 إلى pri_col2 على خريطة الطريق.

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

فريق Angular ، إذا قرأت هذه المشكلة بعد الآن ، فالرجاء فقط إضافة إعداد مترجم لـ "ignoreUnusedComponents" ودعنا نواصل استخدام هذا الإطار.

حسنًا ، لقد وجدت المكان https://github.com/angular/angular/blob/master/packages/compiler/src/aot/compiler.ts#L605tbosch مرحبًا ، هل يمكنك المساعدة هنا وشرح كيفية القيام بذلك يكون تحذيرا بشكل صحيح؟ لا يمكن رؤية أي تحذيرات تم إلقاؤها في مترجم AoT هذا ، فقط الأخطاء. يمكن إضافة خيار المترجم ، كما هو مقترح أعلاه.

هذه القضية هي ألم في المشاريع المعقدة. حالتي الخاصة هي https://github.com/angular/angular/issues/13590#issuecomment -331820496

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

نواجه مشكلات بالطريقة الأخرى أيضًا: إذا أردنا استبدال مكون 1x داخل وحدة نمطية ، فإننا نقوم بإنشاء وحدة نمطية جديدة واستيراد المكونات التي ما زلنا نريدها هناك:

import { HeaderComponent, SidebarComponent } from '@mylibs/layout';
import { FooterComponent } from './footer.component';

@NgModule({ declarations: [ HeaderComponent, SidebarComponent, FooterComponent ] })
export class MyLayoutModule { }

@NgModule({ imports: [ MyLayoutModule ] })
export class AppModule { }

الخطأ هو: `` تم الإعلان عن HeaderComponent في وحدتين: lib / module.ts و app / module.ts
بدلاً من ذلك ، سيسمح لنا التحذير على الأقل بالمضي قدمًا :(

أدركت للتو - عيد ميلاد سعيد لهذه القضية :)

بعد عام واحد ، وما زلنا لا نستطيع تغيير هذا إلى تحذير. سخيف.

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

الرجاء إصلاح هذا. اجعله في تحذير!
تجربتي العامة مع الزاوي 5 aot build أقل من ممتاز.

بعد بعض المناقشة https://gitter.im/angular/angular؟at=5a551f565a9ebe4f756843b2 توصلنا إلى استنتاج مفاده أننا بحاجة إلى إنشاء مكون واحد لكل وحدة حيث يبدو أن الوحدة هي مجرد سياق تجميع وليست طريقة لتجميع الأشياء معًا .. .

هذا يأخذ حجم كتاب التاريخ.

Xesenix ... السياق والتنظيم جزءان من الكل.

فقط في حالة استمرار وجود أي مشكلة مع هذا ، يمكنك تشغيل هذا البرنامج النصي كبرنامج نصي لما بعد التثبيت كحل بديل

const replace = require('replace-in-file');
const filesToFix = [
    {
        files: 'node_modules/@angular/compiler/esm2015/compiler.js',
        from: ['throw syntaxError(messages.join(\'\\n\'));'],
                // Actually this does nothing , just leave it blank should do
        to: [`console.warn(\'Angular compiler warning\');\n\t\tconsole.warn(messages.join(\'\\n\'));`]
    }
]

filesToFix.forEach((i) => {
    try {

        const changes = replace.sync(i);
        if (changes.length > 0) {
            console.log('Modified files:', changes.join(', '));
        }
    }
    catch (error) {
        console.error('Error occurred:', error);
    }
});

سيستخدم المترجم الزاوي الإخراج من tsconfig ، لذا قم بتغيير _tsconfig.app.json_ لاستبعاد تلك الملفات التي لا تريد تضمينها
على سبيل المثال
"exclude": [ "test.ts", "**/*.spec.ts", "**/*.mock.component.ts", ]

@ andela-andrewmakenzi هذا ما تم اقتراحه من قبل ، وأبعد من ذلك في هذه الدردشة العملاقة (لا عيب على الإطلاق في عدم قراءة كل شيء). ومع ذلك ، تظهر المشكلات إذا كنت تعتمد على مكون واحد في مكتبة تستخدم ملفات برميل (index.ts). إذا قمت باستيراد أي مكون من ملف برميل ، فسيحاول المترجم تحميل جميع المكونات المشار إليها في ملف البرميل هذا ، وسيشتكي من أنها ليست في وحدة نمطية. هذا يجعل من الصعب حزم مكتبات المكونات القابلة لإعادة الاستخدام ، والتي هي أساسًا النقطة الكاملة لبنية المكونات في المقام الأول.

يعمل الحل الخاص بك بشكل رائع مع الأشخاص الذين لديهم مكونات وهمية ويواجهون هذا الخطأ عندما لا يجرون اختبارات. ولكن إذا حاولت مؤسستك (مثل منظمتي) إنشاء مكتبة مكونات مشتركة ، وسحب فقط تلك التي نحتاجها لأي مشروع معين ، فلن يساعدك استبعاد TSC للأسف.

@ andela-andrewmakenzi: يبدو أن اقتراحك يساعد في الوقت الحالي ، والمشكلة السابقة هي أن لدي مكونًا لاختبار الوحدة مثل (.spec) ولا أرغب في تضمينه في AOT-build (وربما بعض المكونات الوهمية التي لا أرغب حتى في الحصول عليها في عرضي) ربما تمت معالجة هذا بطريقة ما في الإصدار الأحدث من Angular على ما أعتقد :)

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

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

في رأيي ، يجب أن يكون كل مكون بمفرده NgModule . ليس من المخيف إنشاء NgModule آخر لكل مكون. (مثل ما فعله @angular/material )

أعتقد أنها مشكلة افتراضية حقًا. لا يمكننا أيضًا رؤية أي سبب لامتلاك أي شيء في منتصف الطريق. ليست NgModule ، وليست حزمة ، وليست خارج شجرة التطبيق ... شيء يبدو أنه رمز ميت.

لذلك مع new @ angular / cli (1.7.0+) ، حتى IgnoreModule بطريقة ما لا يعمل على حل هذه المشكلة.

في رأيي ، يجب أن يكون كل مكون في NgModule الخاص به

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

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

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

dborisenkowork لست متأكدًا مما إذا كنت لم تره (أو إذا لم يعمل مع حالة الاستخدام الخاصة بك) ولكن الحل @ rahul-sivalenka-wtc المقدم يعمل بشكل مثالي.

هل انتقل أي شخص مؤخرًا من الزاوية 4 إلى الزاوية 5 ولاحظ أن بعض مكوناتها التي تم الإعلان عنها بالفعل في الوحدات النمطية تؤدي إلى حدوث هذا الخطأ؟

@ novologic-clay ما الخطأ؟ الموضوع طويل ، هل تشير إلى الخطأ الأصلي
تجميع Angular2 AOT - "لا يمكن تحديد الوحدة النمطية للفئة (... العديد من المكونات غير المستخدمة)" ؟

@ andela-andrewmakenzi نعم ولا. إنه نفس الخطأ الذي تمت طباعته عند محاولة التحويل البرمجي ، ولكن المكون الذي يشكو منه مضمّن بالتأكيد في وحدة نمطية. أقوم بالترحيل من 4.3.6 إلى 5.2.4 ، ولم أحصل على هذا الخطأ لهذا المكون المحدد لأنني قمت بتحديث إصداري من الزاوية ، وقمت بتجميع AOT على 4.3.6 قبل أن أبدأ في الترحيل كاختبار دخان .

@ novologic-clay هل يمكنك مشاركة أخطاء وحدة التحكم الخاصة بك؟

... يجب أن يكون الهدف النهائي هو استخدام tsconfig.json option "noUnusedLocals": true الذي يلغي كل ما هو غير مستخدم.

@ andela-andrewmakenzi

ERROR in : Cannot determine the module for class InlineAddComponent in /Users/claygarland/CatalsytConnect/frontend/Talon/src/app/core/component/input/inline-add/inline-add.component.ts! Add InlineAddComponent to the NgModule to fix it.

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

**COMPONENT:**
import {Component, Inject, Input} from '@angular/core';
import {MAT_DIALOG_DATA, MatDialogRef} from '@angular/material';
import {ActivatedRoute} from '@angular/router';
import {BaseForm} from '../../form/form/BaseForm';
import {FormDataService, FormDataServiceProvider} from '../../form/form/FormDataService';
import {BaseApi} from '../../../api/BaseApi';

@Component({
    selector: 'inline-add',
    templateUrl: './inline-add.component.html',
    styleUrls: ['./inline-add.component.scss'],
    providers: [
        FormDataServiceProvider
    ]
})
export class InlineAddComponent extends BaseForm {

    @Input() title = 'Entity';
    @Input() formName;

    protected service: BaseApi;

    constructor(
        protected route: ActivatedRoute,
        protected formDataService: FormDataService,
        public dialogRef: MatDialogRef<InlineAddComponent>,
        @Inject(MAT_DIALOG_DATA) public data: {
            form: string,
            title: string,
            service: BaseApi,
        },
    ) {
        super();
        this.title = data.title;
        this.formName = data.form;
        this.service = data.service;
    }

    submit() {
        super.onSubmit(res => {
            this.dialogRef.close(res.data[0]);
        });

    }

    onCancel() {
        this.dialogRef.close(false);
    }

}

**MODULE:**
import { NgModule } from '@angular/core';
import {SharedModule} from '../../../shared/shared.module';
import {InlineAddComponent} from './inline-add/inline-add.component';


@NgModule({
    imports: [
        SharedModule,
    ],
    declarations: [
        InlineAddComponent,
    ],
    exports: [
        InlineAddComponent,
    ],
    entryComponents: [
        InlineAddComponent,
    ]
})
export class FormInputsModule { }

وتجدر الإشارة أيضًا إلى أنه عند تشغيل هذا التطبيق في خدمة ng ، يعمل المكون بشكل جيد.

يجب ألا تكون المكونات المزيفة المستخدمة في اختبارات العديد من المكونات الحقيقية في وحدة نمطية ؛ يتم تضمينها فقط في TestBed للمكونات المختبرة.
هذا الخطأ غبي. الرجاء حل هذا كما هو خلال من سنة واحدة.

إزالة "التصدير" حتى لا تأخذها ts إلى البناء.

@ tony-kaplan لا يمكنك فعل ذلك إذا لم يكن لديك noUnusedLocals في tsconfig الخاص بك ، ولا إذا كنت تريد استخدام الكود في حالات الاختبار أو ما شابه ذلك.

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

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

يا ولد! الكثير من أجل إطار عمل مؤسسي ...

@ أتوم مورغان الحل البديل الذي تتحدث عنه؟

netlander هذا واحد

حقًا ، لا يمكنني فعل أي شيء حيال الخطأ "لا يمكن تحديد الوحدة النمطية لفئة DaterangepickerDirective"؟

أي شخص يساعدني أيضا؟ بعد هذا المنصب الميجازورد!

لا أوافق على إضافة استثناءات جديدة في tsconfig.app.json إلى هذا التوجيه! كيف يمكنني التحويل البرمجي باستخدام --aot param بدون هذه المشكلة؟

حالة الاستخدام الخاصة بي https://github.com/angular/angular/issues/23475
أقوم بإنشاء مكتبة المدققين ولا أريد إنشاء وحدة نمطية لكل توجيه مدقق ، كل ما أريده هو فقط أن أكون قادرًا على تجميع توجيهات المدقق لحزمة npm حتى يتمكن المستخدم من تثبيت واستيراد أدوات التحقق التي يحتاجها إلى NgModule فقط. كما أنني لا أرغب في إنشاء وحدة واحدة لجميع المدققين لأنهم سيتم تجميعهم جميعًا في الحزمة النهائية وهو ما يمثل إهدارًا كبيرًا للحجم.

يسعدني إنشاء علاقات عامة لإصلاح المشكلة.

anjmao هذا مشابه بشكل لا يصدق لسبب فتح هذا في المقام الأول. كحل بديل لمكتبة صغيرة ، وجدنا أن هذا الخطأ لا يحدث إذا كنت لا تستخدم ملفات برميل (index.ts). يبدو أنك إذا قمت باستيراد مكون / توجيه واحد من فهرس ، فإنه يحاول العثور على وحدة نمطية لجميع عمليات التصدير الأخرى لملف الفهرس.

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

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

import { NgModule } from '@angular/core';

@NgModule({
    imports: [],
    declarations: [
        MyComponent,
        MyPipe,
        MyDirective,
        ...
    ],
})
export class DummyModule {
}

هل هناك سبب لعدم حل هذه المشكلة حتى الآن؟

هل حل "اجعله تحذيرًا" غير ملائم؟ هل يمكن لأحد أعضاء الفريق الأساسي التعليق على هذا؟

في حالتي ، الأمور تسير على ما يرام مع NG 5 و CLI و AOT. ولكن بعد الترقية إلى NG 6 ، أحصل على خطأ مشابه لمكون غير مستخدم. في الواقع يتم استخدام المكون من خلال خدمة يتم حقنها في المكون الآخر. لدي العديد من المكونات المماثلة التي تم إنشاؤها واستخدامها بنفس الطريقة. لكن واحدًا فقط لديه مشكلة واحدة في الترقية إلى أحدث NG CLI 6.0 و 6.0.1

واتضح للتو ، في أحد المراجع ، أن لدي مرجع الملف في حالة خاطئة. لدي ملف index.ts لتصدير جميع المكونات في نفس الدليل. كان لدي
export * from './dateTimePicker.component'
بينما كان يجب أن يكون:
تصدير * من "./datetimePicker.component" ؛

من الواضح أن NG CLI 6 مقيدة أكثر للغلاف حتى في Windows ، بينما NG CLI 1.x مريحة بعض الشيء.
من الواضح أن مثل هذا التقييد جيد وصحيح ، لذلك يمكن أن يعمل نفس مصدر الشفرة بشكل جيد في Linux وهو أمر حساس لحالة الأحرف بشكل افتراضي.

حالة استخدام أخرى لهذا:

يتيح لك Typescript إعداد مسارات دقة متعددة باستخدام المتغير paths في tsconfig.json . السابق:

{
    ...
    "paths": {
        "~src/*": ["src/*", "src-gen/*"]
    }
}

السماح لك باستيراد أشياء مثل هذا:

import { NgModule } from "@angular/core";
import { ExampleComponent } from "~src/example.component";

@NgModule({
    declarations: [
        ExampleComponent
    ],
})
export class ExampleModule {}

إذا كنت تقوم بإنشاء مكون داخل src-gen يمكن للمطور "تجاوزه" عن طريق إنشاء مكون آخر داخل المجلد src ، فسيبدأ نفس الخطأ في الحدوث مع المكون (غير المستخدم الآن) داخل src-gen (والذي لا يجب حذفه ، حيث يمكن تمديده بواسطة تجاوز).

حالة استخدام أخرى محتملة:

مكونات خاصة بالبيئة. أنا أخلعهم من أجل الإنتاج.

const environmentComponents = production ? [] : [
  DevOnlyComponent,
];

@NgModule({
  declarations: [
    ...environmentComponents,
  ],
})
export class ExampleModule {
}

تمكنت من الحصول على كل شيء آخر يعمل مع مكونات خاصة بالبيئة وهذا ما يوقفني. 😪

نواجه هذه المشكلة عند تنفيذ آلية لتخصيص الإنشاء (يتم تبادل المكونات لمشاريع Angular CLI مختلفة) والتي تشبه إلى حد كبير السيناريو الموصوف بواسطة tiagodws (بما في ذلك امتداد المكون الأصلي).

هل هناك أي تحديث / رأي من فريق أساسي حول هذه المسألة؟

بعد أكثر من عام من فتح هذه المشكلة ، يتمثل أسلوبي الجديد في تقليل استخدام ملفات البرميل. إذا كنت تستخدم مسارات TS مثل ~components/button/component في وارداتك في كل مكان ، فسيتم تجاهل الواردات غير المستخدمة. إذا تمت الإشارة إلى هذا المكون غير المستخدم في ملف برميل ، فسيتم طرحه.

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

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

خيار الاستبعاد لا ينطبق على الأنبوب الوهمي:

@Pipe({ name: 'translate' })
export class MockTranslatePipe implements PipeTransform {
    transform(value: string): string {
        //Do stuff here, if you want
        return value;
    }
}

لقد استبعدت tsconfig.app.json هذا الملف:

"exclude": [
        "test.ts",
        "**/*.mock.ts",
        "**/*.spec.ts"
    ]

ومع ذلك ، عندما أقوم بتشغيل ng-xi18n --i18nFormat = xlf2 --outFile =. / الأصول / i18n / messages.xlf ، فإنه لا يزال يشكو:

لا يمكن تحديد الوحدة النمطية للفئة MockTranslatePipe في src / test / translate.service.mock.ts! أضف MockTranslatePipe إلى NgModule لإصلاحه.

كانت مشكلتي أنه كان لدي اسم فصل في مكونين مختلفين عن طريق نسخ ولصق لول! في وقت لاحق نفس الخطأ في عدم الاهتمام الممارسة الجيدة تجعل الرجال مثاليين! يضرب ...
التوقيع: ساتوشي ناكاموتو: ق

على غرار yuezhizizhang ، ما زلت أواجه هذه المشكلة ، حتى بعد إضافة الكرة الأرضية للسخرية إلى المسار tsconfig.app.json exclude .

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

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

استمرت المشكلة. أضفت أيضًا الملف الذي أرغب في تخطي الإصدار (فئة الملخص) إلى قسم الاستبعاد tsconfig.app.json وما زلت أحصل على:

لا يمكن تحديد الوحدة النمطية للفئة MapElementBaseComponent في ... / map-element / map-element-base.component.ts! أضف MapElementBaseComponent إلى NgModule لإصلاحه.

لقد تخلصت من هذه المشكلة بعد التحقق مرتين من الواردات

ср، 14 нояб. 2018 г.، 15:13 دانيال جروه [email protected] :

استمرت المشكلة. لقد أضفت أيضًا الملف الذي أرغب في تخطي الإنشاء
(فئة مجردة) إلى قسم الاستبعاد من tsconfig.app.json وأنا
ابقى خذ:

لا يمكن تحديد الوحدة النمطية للفئة MapElementBaseComponent بتنسيق
... / map-element / map-element-base.component.ts! أضف MapElementBaseComponent
إلى NgModule لإصلاحه.

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

عندما يكون TypeScript صارمًا ، فإن الاستيراد الزاوي ، في تجميع AOT ، لا يستخدم مكونات من مكتبة ويؤمن هذا الخطأ ... تحقق من أن المكونات / الوحدات غير المستخدمة لا معنى لها ...

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

هذا الخطأ سخيف للغاية. كان لدي وحدة نمطية كانت تحدد المكونات في كائن ، مثل:

const landingComponents = {
    'landing-root': LandingComponent,
    'get-notified': GetNotifiedComponent,
    'typed-component': TypedComponent,
    'sticky-bar': StickyBarComponent,
};

ثم حاولت تغذية الوحدة بـ declarations: Object.values(landingComponents) ، entryComponents: Object.values(landingComponents) .

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

بقدر ما أحب Angular ، فإن مترجم AOT يبدو وكأنه حساء فوضوي من التعويذات السحرية.

لقد قيل عدة مرات ولكن الحل هو مكون واحد لكل وحدة لهذا ولست متأكدًا مما إذا كنت قد لاحظت من PRs إلى Angular ولكن تم دمج هذا مؤخرًا وقد يكون ذا أهمية في هذا الموضوع: https://github.com/ الزاوي / الزاوي / سحب / 27481

اليوم أصبح عمر هذه القضية عامين 🎉

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

tiagodws لول منذ متى وأنت تنتظر لنشر هذا؟ هل قمت بتعيين تذكير؟

فقط لمعلوماتك
كانت مشكلتي هي نفسها https://github.com/angular/angular/issues/13590#issuecomment -389113560
يبدو أن الواردات حساسة لحالة الأحرف في وضع AOT

peterdeme ... JavaScript حساس لحالة الأحرف (والمسارات كسلاسل متشابهة ... = تعتمد على Linux وليس على Windows).

مرحبًا يا رفاق ، لقد ظهرت للتو في احتفال متأخر بسنتين. هناك الكثير من الحديث المتبادل حول الأسباب المحتملة للأشخاص ، بما في ذلك الأقسام include و exclude من tsconfig.json ، لذلك أريد فقط توضيح المشكلة الجذرية لهذا الموضوع.

إذا أنشأت مكتبة من المكونات التي يمكن إعادة استخدامها ، وأضفت ملفات برميل ( index.ts ) لتسهيل الاستيراد ، فحينئذٍ سيتعطل برنامج التحويل البرمجي Angular عند استخدام أي منها. هذا لأنه بمجرد استيراد أي شيء من هذا الملف (على سبيل المثال ، @shared/components ) ، سيحاول العثور على الوحدة النمطية لكل عنصر واحد. حتى إذا قمت بتحديد المكونات المحددة التي تريدها (على سبيل المثال import { SharedToastComponent } from '@shared/components'; ) ، فسيظل المترجم يبحث عن الوحدة النمطية لكل مكون مُصدَّر ، ويرمي خطأ (وليس تحذيرًا) حول المكونات المفقودة.

من الواضح أن هناك حلولاً بديلة.

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

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

نأمل أن يفعل فريق Angular في عام 2019 شيئًا حيال هذه المشكلة القديمة جدًا والمزعجة جدًا. 🤞

@ swimmadude66 ... لم تذكر طريقة إنشاء وحدة lib حقيقية وإضافتها إلى تطبيق Angular عبر tsconfig.json ... مثل: "paths": {"ng-demo": ["./packages/ng-demo/src/index.ts"]} واستخدامها عبر استيراد مثل import { DemoModule } from 'ng-demo'; . بهذه الطريقة تلغي الحاجة إلى نشر lib في مستودع npm عام / خاص ولكن لا تزال تحترم الدور الأصلي لوحدة lib هذه. لذلك فهو يعمل بشفافية في تطبيقك وليس لديك أي مشاكل.

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

هذا ليس ثابتًا حتى في AOT. لا يعطي Angular CLI أخطاء عند التشغيل مع الإرسال (والذي يستخدم AOT افتراضيًا) ولكنه يعطي أخطاء تشغيل مع build.

أفهم أن هذا ليس Angular CLI repo ، لكن بالتأكيد السلوك المحيط بهذا غريب.

حتى مع الحل البديل لإنشاء وحدة نموذجية ، ستفشل "بنية ng" الآن إذا نسي كاتب اختبار وحدة واجهة المستخدم إضافة مكون وهمي واحد إلى وحدة نموذجية.

أعلاه يعني أن اختبار وحدة واجهة المستخدم هو حاليًا عنصر خطر لخط أنابيب نشر CI / CD!

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

كخيار مؤقت: لماذا لا تجعل الخطأ الذي يظهر في "ng build" أكثر إفادة لكتاب الاختبار: على سبيل المثال ، أضف نصًا إضافيًا لتأثير "إذا كان هذا مكونًا وهميًا مستخدمًا في الاختبار: أضفه إلى وحدة نموذجية في ذلك ملف حسب (عنوان url هذا) "

كيف وصلت اختبارات وحدة الكتابة في Angular dev الودية إلى هنا:

أ) IMHO هي ممارسة DRY-code لإنشاء ملف "مساعد" لوضع المكونات الوهمية ، والخدمات ، وما إلى ذلك التي تستخدمها جميع ملفات .spec. ومع ذلك ، فإن هذه الممارسة تدير جهاز الاختبار في سيناريو الخطأ هذا.

ب) يمكن لجميع ملفات .spec استيراد هذا الملف "المساعد" دون الحاجة إلى "وحدة نموذجية" لا علاقة لها بكود الاختبار الفعلي. المكونات الوهمية مفيدة كما هي ، بدون عضوية في وحدة نموذجية ليس لها دور في بيئة اختبار المواصفات على الإطلاق.

من المؤكد أن الحل البديل تافه ... ولكن مجرد العثور على هذا الخطأ عبر بحث google ، وقراءة واستيعاب الخيط والحلول المفيدة لم يكن كذلك.

أقوم فقط بإضافة هذا إلى نهاية ملف المساعد الذي يحتوي على المكونات الوهمية (من بين أشياء أخرى):

/*
  mock components
  !! Each mock component added to this file *must* be added to the "MockTestModule", see below !!
*/
@Component({
  selector: 'app-mock-component',
  template: '<span>mock widget</span>'
})
export class MockComponent {}

/*
  This is an unused module to resolve the ng build error:
    'ERROR in : Cannot determine the module for class MockComponent
    in C:/code/myRepo/src/assets/test/test-resources.ts!
    Add MockComponent to the NgModule to fix it.'

  Reference: https://github.com/angular/issues/13590

  Each mock component added to this file *must* be added to the "MockTestModule"
*/
@NgModule({
  declarations: [ MockComponent ],
})
export class MockTestModule {}

لاحظ أن الملف أعلاه كبير جدًا في الواقع ... يتم دفن "MockTestModule" في نهاية الملف المساعد ...

... آمل ألا نضطر إلى كتابة إدخال package.json لـ "ng build" يعترض المكالمة ، ويدرج رسالة وحدة التحكم "مرحبًا مختبرو وحدة واجهة المستخدم ، هل أضفت المكون الوهمي إلى الوحدة النمطية الوهمية؟" دفع.

إليكم ما حل المشكلة بالنسبة لي. هيكلي هو كما يلي:

├── icons.module.ts
├── index.ts
├── icon
│   ├── icon.component.html
│   ├── icon.component.ts
│   └── icon.module.ts
└── icon-indicator
    ├── icon-indicator.component.html
    ├── icon-indicator.component.ts
    └── icon-indicator.module.ts

في icons.module.ts كان لدي:

import { IconComponent } from './icon/icon.component';
import { IconIndicatorComponent } from './icon-indicator/icon-indicator.component';

export { IconIndicatorComponent, IconComponent };

@NgModule({
  /* this was all fine */ 
})
export class IconsModule {}

index.ts كان:

export * from './icons.module';

أفترض أن المشكلة تكمن في أن المترجم لم يقم بتحليل الأيقونة ووحدات مؤشر الأيقونة قبل مواجهة المكونات المقابلة ، وبالتالي ألقى الخطأ Cannot determine the module for class . هذا المشروع هو ng 5. لقد حصلت على الخطأ فقط عندما استهلكته في مشروع ng 7.

الحل هو نقل الصادرات مستوى واحد لأسفل. لذلك قمت بإزالة بيان التصدير icons.module.ts ونقلته إلى:

icon.module.ts:
export { IconComponent };
...

icon-indicator.module.ts:
export { IconIndicatorComponent };
...

وتعديل index.ts :

export * from './icons.module';
export * from './icon/icon.module';
export * from './icon-indicator/icon-indicator.module';

أمل أن هذا يساعد شخصاما.

أعتقد أن عارض اللبلاب الجديد سيحل بعض المشكلات مع AOT. كما ترون من طلبات السحب والمشكلات ، يركز الفريق الزاوي على اللبلاب ، لذلك لا فائدة من فعل شيء حيال هذه المشكلة على الزاوية 6.

أعتقد أن عارض اللبلاب الجديد سيحل بعض المشكلات مع AOT.

أحب سماع هذا في كل قضية.

أواجه هذه المشكلة أيضًا في الزاوية 7.2.0 والزاوية 7.3.0

ERROR in : Cannot determine the module for class ModalMockComponent in /Users/user/repos/angular-skeleton/src/app/shared/modal/modal.component.mock.ts! Add ModalMockComponent to the NgModule to fix it.
Cannot determine the module for class TranslatePipeMock in /Users/user/repos/angular-skeleton/src/app/shared/pipes/translate.pipe.mock.ts! Add TranslatePipeMock to the NgModule to fix it.

على سبيل المثال ، لدي TranslatePipe و TranslatePipeMock بداخل Shared Module . تم تضمين TranslatePipe في الوحدة النمطية ، بينما الأنبوب الوهمي ليس كذلك.
translate.pipe.mock.ts مخصص لغرض اختبار الوحدة ، لذا يمكنني فقط استيراد هذا الملف إلى كل اختبار وحدة.

ولكن الآن فشل بنائي
ng build --prod

كيف يمكننا حل هذه المشكلة؟

لدى ATM حل بديل يحلها

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "outDir": "../out-tsc/app",
    "types": []
  },
  "exclude": [
    "test.ts",
    "**/*.spec.ts",
    "**/*.mock.ts"
  ]
}

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

rrmayer ، من المرجح أن تكون حالة هذه المشكلة مجرد "انتظر لبلاب" ، كما هو الحال مع جميع المشكلات "الحالية" تقريبًا.

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

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

ليس لدي أمل في أن يتم إصلاحه للمترجم الحالي: D

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

يمكن أن تتسبب عمليات الاستيراد غير المستخدمة في حدوث هذا الخطأ ..

import { UnusedImportComponent } from "./used-somewhere-else-or-not.component";

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

هناك حل رغم ذلك! لنفترض أنه تم التصريح عن المكون الأساسي الخاص بنا على النحو التالي:

@Component({
  selector: 'app-user-stub-component',
  template: ''
})
export class UserStubComponent {}

يتعين علينا إزالة الكلمة الأساسية "تصدير" ولكن لا يزال يتعين علينا بطريقة ما تصدير المكون لاستخدامه في وحدة الاختبار / الاختبار. افعلها مثل هذا:

@Component({
  selector: 'app-user-stub-component',
  template: ''
})
class UserStubComponent {}

export default UserStubComponent;

الآن ، في كل مكان عندما تقوم باستيراد كعب الروتين ، علينا تجنب الأقواس كما يلي:
import UserStubComponent from 'path'

نأمل أن يعمل. بالنسبة لي يحل مشاكل تجميع AOT.

في حالتي ، أصلحته. كانت المشكلة مع الغلاف. لقد استخدمت الأحرف الكبيرة للمجلدات ولكن الاستيراد التلقائي لرمز VS استورد المسار بأحرف صغيرة.

@ renilbabu03 JS حساس لحالة الأحرف.

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

لقد غيرت export class إلى default export :

import { PipeTransform, Pipe } from '@angular/core';

@Pipe({
  name: 'translate'
})
class TranslatePipeMock implements PipeTransform { // <-- NOT: "export class TranslatePipeMock implements PipeTransform"
  public name = 'translate';

  public transform(query: string): any {
    return query;
  }
}

export default TranslatePipeMock;

أي إصلاحات لهذا؟
لقد جربت export default <class> ولكن عندما أقوم بتشغيل ng serve --aot ، حدث خطأ: تم تصدير قيمة غير متوقعة "فارغة" بواسطة الوحدة النمطية .

إنه محبط للغاية.

redplane لماذا تريد أن تفعل ذلك؟ أعني تصدير default .

إليك كيف يفعلون ذلك بأنفسهم:
https://github.com/angular/angular/blob/master/aio/content/examples/testing/src/testing/router-link-directive-stub.ts

ما لم أقم بإصدار $ import an exported أحد الأصول ، فلماذا يهتم Angular بوجود الملف؟

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

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

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

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

لحل هذا الخطأ ، يجب أن أقوم بتصريح التعدادات الخاصة بي في ملف public-api.ts وكذلك استخدامها في مشروع التطبيق مع استيراد مباشر من المكتبة وليس بمسار استيراد نسبي.

علي سبيل المثال:
اسم مشروع المكتبة: element-lib
اسم مشروع التطبيق: demo-app

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

استيراد {SearchEnum} من 'element-lib' ؛

ولا تفعل
استيراد {SearchEnum} من '../../../projects/components-lib/path-to-your-component'؛

آمل أن يساعد هذا شخصًا ما في المستقبل ، حيث قضيت ساعات في العثور على هذا بنفسي.

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

أقدم من خلال المكتبة بعض فئات المرافق التي يمكن أن تمتد مكوناتك عليها. في تلك السلسلة من الفصول الرئيسية ، بعض هذه الصفوف مجردة ويجب أن يكون لدى ng 9 @Directive({ selector: 'random' }) ليكون متوافقًا مع ng 8.

لذلك كدت أن أفلت من العقاب ... لكن:

Cannot determine the module for class NgxSubFormComponent in /........./node_modules/ngx-sub-form/ngx-sub-form.d.ts! Add NgxSubFormComponent to the NgModule to fix it.`

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

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

مرحبًا بالجميع ، آسف للصمت بشأن هذه المسألة.

ينشئ ngc في View Engine ، حسب التصميم ، ملفات ngfactory لكل مكون في "التجميع" - أي المجموعة الكاملة من ملفات TS المحددة بواسطة tsconfig الخاص بك. هذه هي الطريقة التي يستخدمها TypeScript
يعمل بنفسه - يقوم بتجميع جميع الملفات المحددة بواسطة tsconfig. يقوم ngc بمعالجة إضافية علاوة على ذلك.

لذلك إذا كان @Component موجودًا في هذا التجميع ويمكن لـ ngc رؤيته (بمعنى أنه من المستوى الأعلى وتم تصديره) ، سيحاول ngc تجميعه. لا توجد طريقة للتغلب على هذا بخلاف التأكد من عدم قيام ngc بترجمة الملف الذي يعلن المكون في المقام الأول.

الطريقة الصحيحة للقيام بذلك هي تحديد نطاق tsconfig الخاص بك. على سبيل المثال ، قد يكون لديك tsconfig عالي المستوى للمحرر الخاص بك ، والذي يتضمن جميع الملفات ، ثم tsconfig.app.json لتجميع التطبيق الخاص بك على وجه التحديد ، والذي يرث من تكوين المحرر ويستبعد ملفات المواصفات. سيتم تجميع تكوين التطبيق فقط باستخدام ngc.

يجب هيكلة المشاريع (كل tsconfig هو "مشروع") بحيث يتم دائمًا تجميع المكون والوحدة النمطية الخاصة به معًا.

في Ivy ، لا تزال نفس القواعد سارية إلى حد كبير ، مع وجود عدة اختلافات صغيرة:

• بشكل افتراضي ، سيحاول Ivy تجميع _any_ @Component ، بغض النظر عما إذا كان قد تم تصديره أم لا.
• لم يعد من الخطأ ، في Ivy ، أن يكون لديك مكون بدون وحدة نمطية. ومع ذلك ، ستستمر في الحصول على أخطاء فحص نوع القالب إذا حاول هذا المكون استخدام مكونات / توجيهات أخرى في القالب الخاص به ، لأنه بدون وحدة نمطية ، لن يكون أي شيء آخر مرئيًا لهذا المكون.
• من الممكن إخبار مترجم Ivy بتجاهل مكون أو وحدة معينة وتركه حتى وقت التشغيل ، عن طريق إضافة علامة jit: true إلى المصمم.

alxhub يسعدني أن أسمع أنه لم يعد خطأ!

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

فيما يتعلق بالقيود المتبقية مع Ivy (أخطاء القوالب في المكونات التي لا تحتوي على وحدات نمطية) ، هل من المبالغة أن نطلب منها أن تكون تحذيرات أيضًا؟ أتفهم أن ذلك قد يكون أكثر صعوبة (أو مستحيلًا) إذا حدث فحص النوع قبل تحديد المكون على أنه أقل من وحدة نمطية ، ولكن يبدو لي أنه تحذير على غرار Warning: ExampleUnusedComponent does not belong to an NgModule, and will be excluded from the output يلتقط بدقة فكرة أن لن يتم تضمين المكون (وأي مكونات أخرى مشار إليها) ما لم تتم إضافتها إلى وحدة ngModule.

بشكل عام ، أنا متحمس جدًا لرؤية حركة بشأن هذه المشكلة ، وأتطلع إلى تجربة حالة الاستخدام الأصلية الخاصة بي مع التغييرات الجديدة في مترجم Ivy!