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 , поскольку мы не используем ОбзорКомпонент из @project/angular.

Поскольку буквально ни один файл не указывает на @project/angular/components/home/overview/component.ts , я не ожидал, что компилятор вообще заботится о том, чтобы он не использовался. но поскольку файл существует внутри каталога node_modules нашего проекта, компилятор находит его, жалуется и умирает.

Что касается 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 компилирует все, что компилирует tsc. И он попытается скомпилировать каждый найденный компонент. Однако 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

Angular 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 и проигнорировали node_modules в нашем tsConfig. Я упоминал выше, что это все еще не работает, но только потому, что мы использовали файлы бочек. Если вы укажете непосредственно на каждый нужный вам класс внутри node_modules, он проигнорирует остальные. Однако, как только вы указываете на бочку, выдает ошибку о неиспользуемых файлах в той же бочке.

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

Все еще надеюсь, что эта ошибка будет понижена до предупреждения

На данный момент в команде Angular проделана отличная работа.
Мы активно используем Angular в наших проектах, и после года попыток разобраться во всех этих модных штуках Angular2+ я пришел к следующему выводу:
1- Angular массивный и медленный, вы хотите сделать его быстрым? используйте AOT и LazyLoading и gzip ваши вещи.
2- Вы хотите отложенную загрузку компонента? НЕТ, вы сможете лениво загрузить маршрут, поэтому, если ваше приложение большое, но содержит только одну страницу, наслаждайтесь размером пакета 8 мг.
3- Вы хотите использовать AOT ?? AOT глючит, и его трудно соблюдать, а также не использовать кучу функций javascript/es6 и, возможно, переписывать много вашего кода.
4- Вы используете AOT в порядке? Хорошо, теперь взгляните на ваш окончательный пакет, теперь он даже больше, чем @angular/compiler плюс ваши компоненты, не подвергшиеся AOT, молодец.

5-В рамках преимущества Angular2+ вы теперь имеете право использовать gzip, на всякий случай, если вы не знали, как его использовать раньше, теперь, когда Angular огромен, вы изучите его лучше :) Так вот, они продаем gziping как вариант оптимизации кода Angular2 :)

@ xe4me Пожалуйста, продолжайте обсуждение в этой теме, относящееся к рассматриваемой проблеме, а не просто разглагольствуйте о фреймворке.

build:dev в https://github.com/AngularClass/angular2-webpack-starter автоматически преобразует строку в массив строк в соответствии с определением функции, build:aot показывает ошибку. Во время разработки выясняется, что необходимы частые сборки AOT.

У меня такая же проблема, и я нашел решение, возможно, оно работает и у вас.

Мой сценарий был следующим:

У меня есть MapPipes.ts, содержащий два канала.

Один из пайпов использовался в моем модуле, а другой нет. Таким образом, я не зарегистрировал второй в части «объявления:» моего декоратора @NgModule . Проблема случилась с этой секунды.

Я зарегистрировал и это (несмотря на то, что оно не использовалось), и теперь оно работает.

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

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

@DzmitryShylovich @kirjai это проблема только с TestComponents в файле спецификации, если вы их экспортируете. И поскольку они обычно должны использоваться только в одном и том же файле, нет необходимости их экспортировать. Проблема решена для меня.

Честно говоря, это нелепо, мне действительно нечего сказать об этом, кроме того факта, что я много часов работаю и все еще не могу получить что-то, что работает в JIT, работающем с AOT (я должен четко понимать, что это только один из около полдюжины выпусков).

@cwmrowe это хорошо, но что, если у вас есть один, который повторно используется в нескольких файлах спецификаций? Это кажется сломанным, если честно.

В моем случае я работал над двумя разными проектами в одном и том же основном приложении Angular 2. У меня есть две папки, названные в честь наших клиентов, скажем, some-domain.com и some-other-domain.com . Приложение одинаково для двух проектов и отличается лишь небольшим стилем и некоторыми незначительными пользовательскими компонентами. Сегодня мне нужно скомпилировать приложение для клиента A, а позже я хочу скомпилировать для клиента B. В коде для меня это так же просто, как изменить 1 строку кода:

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 это не работает с jit или aot, или с обоими?

@bigjetplane Вот плункер с проблемой. Есть абстрактный класс с декоратором и все работает в jit. Когда вы удаляете декоратор из абстрактного класса, приложение не может отображаться, потому что не все зависимости могут быть загружены: Can't resolve all parameters for App: (?).

Это наш вариант использования. У нас есть абстрактный класс с конструктором и инжектами. Мы только хотим переопределить некоторые абстрактные методы в дочерних компонентах.

Приведенный пример не работает в aot. Разница между aot и jit для нас большая проблема. Мы разрабатываем с jit. Производственная сборка с aot. Так мы неделю разрабатываем с jit без ошибок и предупреждений и через неделю хотим продакшн билд и получаем множество ошибок ниоткуда. Я предпочитаю переключатель для jit, где я могу включить ошибки. JIT-сборка требует 10-20 секунд. Сборка aot требует 25 минут.

@tbosch Есть что-нибудь об изменении этого на предупреждение? Кажется, со времени моего последнего визита довольно много других присоединились к своим собственным анекдотам, и мне было интересно, не могли бы вы дать нам обновленную информацию.

Спасибо!

У меня такая же проблема.

В моем случае я работал над двумя разными проектами, но включал общие компоненты через проект внутренней библиотеки angular, добавленный как зависимость в package.json.

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

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 (определение поддельного модуля, в котором объявлен компонент-заглушка).

Итак, при использовании компонентов-заглушек для тестирования вы хотите назвать свой компонент с суфиксом 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'

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

Я не уверен, что еще мы можем сделать по этому поводу. Мы попытались обратиться к каждому компоненту, который нам нужен, из общей библиотеки напрямую (не используя файлы index.ts , поскольку они, казалось, извлекают каждый файл, на который есть ссылки в индексе) и переместили всю общую библиотеку в node_modules.

Зачем компилятору знать о каждом компоненте angular в моей папке 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 Понятно . Если вы думаете, что добавление еще одного модуля имеет такое большое значение, я лучше еще раз взгляну на него сам, потому что я не выступал за создание одного неиспользуемого модуля для совместного использования для всего проекта, а за один модуль для каждого отдельного компонента, который мне нужно было освободить. от слишком строгого компилятора - потенциально дусины.

Стоит отметить, что наша общая кодовая база довольно велика, поэтому неиспользуемый модуль будет самым большим модулем в приложении. Наша ситуация не на 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() . Если вы используете компонент в качестве основы - только для наследования от него, но не как компонент, вам не нужно использовать декоратор, а просто наследуйте и используйте декоратор на «преемнике».
Насчет юнит-тестирования - не могу ответить, наверное нужно создавать специальный TestModule? В данный момент я не занимаюсь юнит-тестированием.

@tytskyi Я понял, что наследование декораторов не поддерживается. Это недавно изменилось?

вариант использования - издеваться над подкомпонентом, как показано ниже. Оба нуждаются в директиве @Component для выбора селектора.

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

Тем не менее, это генерирует ошибку компиляции OP AOT.

Я считаю, что это допустимый вариант использования, и в этом случае компиляция AOT чрезмерно усердна и / или игнорирует спецификации как часть проекта.

Возможно, мое решение кому-то поможет: я только что создал фиктивный модуль, в котором объявляются все фиктивные компоненты. Этот модуль ничем не импортируется — он просто поддерживает компилятор AoT. Следовательно, ни один из фиктивных компонентов не является частью скомпилированного кода. Не идеально, но проблема решена.

Я хотел бы услышать о любом лучшем решении.

Это так странно и неловко, что эта проблема была открыта в декабре 2016 года и до сих пор имеет эту проблему. Я преобразовал структуру всего своего приложения, чтобы использовать компиляцию. У меня есть 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 месяцев, и это все еще проблема. Та же проблема здесь ОШИБКА в Cannot
определить модуль для класса PasoFooterComponent

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

@samirotiv У вас есть репродукции?
Как сказал @robwormald

Компилятор Angular просматривает набор файлов, который вы передали в tsconfig, поэтому исключение файлов оттуда должно исключать их из этой проверки.

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

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

И я заметил, что машинописный текст не скомпилировал мои лениво загруженные модули, потому что я использовал параметр tsconfig «файлы».

Я получаю эту ошибку в абстрактном классе (без декораторов)

Недавно сам начал сталкиваться с этой же проблемой.

+1 за изменение ошибки на предупреждение.

Кажется, это легко исправить. Почему задержка?

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

Бывают случаи, когда вы публикуете пакет, который поддерживает разные версии angular. и ожидается, что пользователь выберет один из них.

Например, пакет, который предоставляет файлы как для HttpClient (пользователи Angular >= 4.3), так и для Http (пользователи Angular < 4.3).

В настоящее время ngc либо компилирует все файлы внутри исходного каталога, независимо от того, используете вы их или нет! или сборка не работает.

Я сделал следующее:

Я сохранил все свои компоненты-заглушки/макеты с расширением .mock.ts и обновил массив «exclude» tsconfig.app.json следующим образом:

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

AOT теперь пропускает компиляцию этих файлов

Мы делаем библиотеку npm с общими компонентами, которые должны использоваться не все сразу и бесятся из-за этой проблемы во время компиляции AoT, черт возьми... Единственное решение atm - создать что-то вроде 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, по крайней мере, это должен быть вариант. Вроде детерминироватьмодуль = ложь/истина. Теперь бананы.

Я вернусь 01.11.2017.

Я отвечу на ваше сообщение после моего возвращения.
В срочных случаях, пожалуйста, отправьте копию вашего электронного письма для
по техническим вопросам [email protected] , в противном случае
[email protected]. Затем другой сотрудник просмотрит вашу электронную почту.
принимать.

Примечание. Это автоматический ответ на ваш «Re:
[angular/angular] Компиляция Angular2 AOT - «Не удается определить модуль
для класса (... много неиспользуемых компонентов)" (#13590)" отправлено
23.10.2017 08:13:17.

Это единственное уведомление, которое вы получите во время
этот человек отсутствует.

Как это до сих пор не исправлено почти 1 год спустя? Рву волосы, чтобы заставить AOT работать, но эта проблема ставит меня в тупик.

Спасибо @rahul-sivalenka-wtc за решение!
Мне удалось успешно решить мою проблему, исключив "**/*.mock.ts" из моего tsconfig.app.json , как вы описываете ❤️

Рад, что смог помочь 😊

Я также встретил проблему. Но мне кажется, я просто неправильно указал путь импорта dodule

любые решения? (невозможно определить модуль для компонента angular 5)

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

Вероятно, это должно произойти на severity3: broken . Для тех из нас, у кого есть несколько целей сборки и полиморфные зависимости (многие варианты использования которых были представлены выше), эта проблема не позволяет сборке работать без сумасшедшей сложной настройки сборки.

какое-нибудь хорошее решение этой проблемы? IgnoreModule — это всего лишь обходной путь, но не очень хорошее решение этой проблемы. изменить ошибку на предупреждение было бы здорово!

Наше решение состояло в том, чтобы добавить функцию transform в @ngtools/webpack , которая пропускает файлы через предварительную обработку , и компоненты ifdef , основанные на различных настройках времени компиляции. Очень-очень некрасиво, но функционально.

Попробуйте сначала импортировать все угловые зависимости в 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';

-------------Затем импортировать служебные модули ------------------------

import {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#L605 @tbosch эй, вы можете помочь здесь и сказать, как это сделать быть предупреждение должным образом? В этом компиляторе 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 объявлен в 2 модулях: lib/module.ts и app/module.ts.
Вместо этого предупреждение, по крайней мере, позволило бы нам двигаться вперед :(

Только что понял - с Днем Рождения в этом выпуске :)

Год спустя, и мы ВСЕ ЕЩЕ не можем изменить это на предупреждение. Нелепый.

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

Пожалуйста, исправьте это. Сделайте это предупреждением!
Мой общий опыт работы со сборкой angular 5 aot далеко не звездный.

После некоторого обсуждения 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);
    }
});

Компилятор angular будет использовать вывод из tsconfig, поэтому измените _tsconfig.app.json_ , чтобы исключить те файлы, которые вы не хотите включать.
например
"exclude": [ "test.ts", "**/*.spec.ts", "**/*.mock.component.ts", ]

@andela-andrewmakenzi это предлагалось ранее, далее в этом гигантском чате (абсолютно не стыдно не читать все это). Однако проблемы возникают, если вы зависите от одного компонента в библиотеке, которая использует файлы бочек (index.ts). Если вы импортируете какой-либо компонент из файла бочонка, компилятор попытается загрузить все компоненты, указанные в этом файле барреля, и сообщит, что они не находятся в модуле. Это усложняет упаковку повторно используемых библиотек компонентов, что в первую очередь является основным смыслом компонентной архитектуры.

Ваше решение отлично работает для людей, у которых есть фиктивные компоненты, и они получают эту ошибку, когда не запускают тесты. Но если ваша организация (например, моя) попыталась создать общую библиотеку компонентов и использовать только те, которые нам нужны для любого данного проекта, исключение TSC, к сожалению, вам не поможет.

@andela-andrewmakenzi: ваше предложение, похоже, пока помогает, ранее проблема заключалась в том, что у меня есть компонент для модульного тестирования как (.spec), и я не хотел бы, чтобы он был включен в AOT-сборку (и, возможно, какой-то фиктивный компонент, который Я бы даже не хотел, чтобы это было в моей проекции) Может быть, это как-то было решено в более поздней версии Angular, я думаю :)

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

Это действительно смешно. У нас есть общий модуль NPM, экспортирующий пару каналов/директив, и если вы не импортируете ВСЕ, он выйдет из строя с этой глупой ошибкой. Это действительно должно быть изменено на предупреждение, и оно не должно нарушать компиляцию.

На мой взгляд, каждый компонент должен быть в своем NgModule . Не так уж и страшно создать еще один NgModule для каждого компонента. (Наподобие того, что сделал @angular/material )

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

Таким образом, с новым @angular/cli (1.7.0+) даже IgnoreModule почему-то не решает эту проблему.

На мой взгляд, каждый компонент должен быть в своем собственном NgModule.

Вы вообще пытаетесь писать юнит-тесты? Эта ошибка делает создание тестовых помощников довольно проблематичным.

@sarunint В корпоративных приложениях, подобных тому, для которого я изначально открыл этот билет, это будут сотни модулей с очень сложным импортом для обработки зависимых директив и компонентов. У этого есть очень простое решение: если компилятор не может найти модуль для компонента, выдать предупреждение и избавиться от него в tree-shaking.

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

@dborisenkowork Я не уверен, что вы этого не видели (или это не работает для вашего варианта использования), но решение, предоставленное @rahul-sivalenka-wtc, работает отлично.

Кто-нибудь недавно перешел с angular 4 на angular 5 и заметил, что некоторые из их компонентов, которые фактически объявляются в модулях, выдают эту ошибку?

@novologic-clay какая ошибка? Тема длинная, вы имеете в виду исходную ошибку
Компиляция Angular2 AOT - «Невозможно определить модуль для класса (... многие компоненты, которые не используются)» ?

@andela-andrewmakenzi Да и нет. Это та же ошибка, которая выводится при попытке компиляции, но компонент, на который он жалуется, наверняка включен в модуль. Я перехожу с 4.3.6 на 5.2.4, и у меня не было этой ошибки для этого конкретного компонента, потому что я обновил свою версию angular и выполнил компиляцию AOT на 4.3.6 прямо перед тем, как начал миграцию в качестве дымового теста. .

@novologic-clay, можете поделиться своими ошибками консоли?

... конечной целью должно быть использование опции $ tsconfig.json "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 serve, компонент работает нормально.

Поддельные компоненты, используемые тестами многих реальных компонентов, не должны быть в модуле; Они просто включены в TestBed тестируемых компонентов.
Эта ошибка глупа. Пожалуйста, решите это как есть в течение одного года.

уберите "экспорт", чтобы ts не взял его в сборку.

@tony-kaplan Вы не можете этого сделать, если в вашем tsconfig нет UnusedLocals или если вы хотите использовать код в тестовых примерах или подобных случаях.

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

@gabrielalan Простое решение - превратить эту ошибку в предупреждение. Лучшее решение — добавить флаг, который позволяет рассматривать это как предупреждение или ошибку. Это не отсутствие решений, это отсутствие фактической реализации любого из них.

О, парень! Так много для корпоративной среды...

@atom-morgan, о каком обходном пути вы говорите?

@netlander Этот

Действительно, я ничего не могу сделать с ошибкой «Не удается определить модуль для класса DaterangepickerDirective»?

Мне тоже кто-нибудь помогает? После этого мегазордского поста!

Я не согласен добавлять в tsconfig.app.json новые исключения в эту директиву! Как я могу скомпилировать параметр --aot без этой проблемы?

Мой вариант использования https://github.com/angular/angular/issues/23475
Я создаю библиотеку валидаторов, и я не хочу создавать модуль для каждой директивы валидатора, все, что я хочу, это просто иметь возможность связывать директивы валидатора с пакетом npm, чтобы пользователь мог устанавливать и импортировать только те валидаторы, которые ему нужны, в NgModule. Также я не хочу создавать один модуль для всех валидаторов, потому что все они будут объединены в окончательный пакет, что является огромной тратой размера.

Я рад создать PR, чтобы исправить проблему.

@anjmao , это невероятно похоже на причину, по которой я открыл это в первую очередь. В качестве обходного пути для небольшой библиотеки мы обнаружили, что эта ошибка не возникает, если вы не используете файлы бочек (index.ts). Кажется, что если вы импортируете 1 компонент/директиву из индекса, он попытается найти модуль для всех остальных экспортов индексного файла.

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

Обходной путь, который я использую для своей общей библиотеки компонентов/директив/каналов: создайте простой фиктивный модуль, который ссылается на все объявления классов. Вам не нужно использовать этот модуль в ваших реальных приложениях, он просто должен существовать на диске. Бывший:

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 , в вашем импорте, неиспользуемые импорты игнорируются. Если на этот неиспользуемый компонент есть ссылка в файле бочонка, он будет брошен.

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

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

опция exclude не подходит для фиктивной трубы:

@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=./assets/i18n/messages.xlf, он все еще жалуется:

Не удается определить модуль для класса MockTranslatePipe в src/test/translate.service.mock.ts! Добавьте MockTranslatePipe в NgModule, чтобы исправить это.

Моя проблема заключалась в том, что у меня было имя класса в двух разных компонентах путем копирования и вставки, лол! Позже та же ошибка, что и безразличие. Хорошая практика делает идеальных парней! хиты...
Подпись: Сатоши Накамото: v

Подобно @yuezhizizhang , у меня все еще есть эта проблема, даже после добавления glob для mocks к пути tsconfig.app.json exclude .

Это почти бесит, что это не было решено почти через два года после первоначального билета; это распространенный вариант использования, который НАРУШАЕТ сборки. При написании тестов разработчику в идеале следует создавать моки для пайпов, сервисов и так далее, разве что. Если вы решите это сделать, ваша сборка сломается. Если нет, то ваши файлы спецификаций ссылаются на реальные компоненты/трубы/и т. д., что приводит к очень сильно связанным тестам.

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

проблема сохраняется. Я также добавил файл, который хочу пропустить сборку (абстрактный класс), в раздел исключений tsconfig.app.json и все равно получаю:

Невозможно определить модуль для класса MapElementBaseComponent в .../map-elements/map-element-base.component.ts! Добавьте MapElementBaseComponent в NgModule, чтобы исправить это.

Я избавился от этой проблемы после двойной проверки импорта

ср, 14 нояб. 2018 г., 15:13 Даниэль Грох[email protected] :

проблема сохраняется. Я также добавил файл, который я хочу пропустить при сборке
(абстрактный класс) в раздел исключений tsconfig.app.json, и я
еще получить:

Не удается определить модуль для класса MapElementBaseComponent в
.../map-elements/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 строгий, импорт Angular, в компиляции 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 кажется хаотичной смесью магических заклинаний.

Было сказано пару раз, но решение для этого — 1 компонент на модуль, и я не уверен, заметили ли вы из PR в Angular, но это было недавно объединено и может представлять интерес для этой темы: https://github.com/ угловой/угловой/тянуть/27481

Сегодня этому выпуску исполняется 2 года 🎉

Тем не менее, ни слова от основной команды о том, почему это не может быть просто предупреждением.

@tiagodws, лол, как долго ты ждал, чтобы опубликовать это? Вы установили напоминание?

Просто к вашему сведению
Моя проблема была такой же, как https://github.com/angular/angular/issues/13590#issuecomment -389113560
Импорт, по-видимому, чувствителен к регистру в режиме AOT.

@peterdeme ... JavaScript чувствителен к регистру (и пути в виде строк одинаковы ... = на основе Linux, а не Windows).

Эй, ребята, просто возвращаюсь к запоздалому празднованию 2-летнего выпуска выпуска. Существует много перекрестных разговоров о возможных причинах для людей, включая разделы include и exclude tsconfig.json , поэтому я просто хочу прояснить, в чем основная проблема. для этой темы.

Если вы создадите библиотеку повторно используемых компонентов и добавите файлы бочек ( index.ts ) для упрощения импорта, тогда компилятор Angular сломается при использовании любого из них. Это потому, что как только вы импортируете что-либо из этого файла (скажем, @shared/components ), он попытается найти модуль для КАЖДОГО ОТДЕЛЬНОГО КОМПОНЕНТА. Даже если вы укажете конкретные компоненты, которые вы хотите (например, import { SharedToastComponent } from '@shared/components'; ), компилятор все равно будет искать модуль для каждого экспортируемого компонента и выдаст ошибку (не предупреждение) об отсутствующих компонентах.

Очевидно, что есть обходные пути.

1. Прекратите использовать бочкообразные файлы. Это быстро становится беспорядочным, так как каждый компонент должен быть полностью указан
2. Используйте ExtrasModule и нигде не используйте модуль. Это хорошо работает для людей, у которых есть компоненты, необходимые только для тестирования, но не так хорошо для людей, которые хотят получить из библиотеки компонентов.

Однако, поскольку использование любого из этих обходных путей приводит к точно такому же выходному коду после встряхивания дерева, очевидно, что другие компоненты НЕ НУЖНЫ включать в используемый модуль. Все, о чем я прошу с этой проблемой двухлетней давности, — это превратить эту ошибку в более подходящее предупреждение. Имеет смысл, так как компиляция все равно будет успешной, если ее продолжить.

Мы надеемся, что в 2019 году команда Angular что-то сделает с этой очень старой и очень раздражающей проблемой. 🤞

@swimmadude66 ... вы не упомянули способ создания реального модуля lib и добавления его в приложение Angular через tsconfig.json ... например: "paths": {"ng-demo": ["./packages/ng-demo/src/index.ts"]} и использовать его через импорт, например import { DemoModule } from 'ng-demo'; . Таким образом устраняется необходимость публиковать библиотеку в общедоступном/частном репозитории npm, но при этом сохраняется собственная роль этого модуля библиотеки. Так что это работает прозрачно в вашем приложении, и у вас нет никаких проблем.

Наличие ошибки на каждой заглушке компонента - самая раздражающая вещь. Все тестируют/пишут спецификации, верно? Таким образом, ошибки заглушки компонента должны влиять на всех. Я не говорю, что проблема со стволом менее раздражает. Я просто говорю, что не все делают бочки. Но все должны делать спецификации. Таким образом, проблема спецификаций должна быть самой большой мотивацией для основной команды исправить это. В настоящее время он помечен как «Низкая частота», но должен быть «Высокая частота», потому что любой, кто выполняет модульное тестирование, столкнется с этой проблемой.

Это даже не соответствует AOT. Angular CLI не выдает ошибок при работе с serve (которая по умолчанию использует AOT), но выдает ошибки при запуске с build.

Я понимаю, что это не репозиторий Angular CLI, но, конечно, поведение вокруг этого странное.

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

Вышеупомянутое означает, что модульное тестирование пользовательского интерфейса в настоящее время является элементом риска для конвейера развертывания CI/CD!

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

В качестве временной меры: почему бы просто не сделать ошибку, которая появляется в «ng build», более информативной для авторов тестов: т. е. добавить дополнительный текст для эффекта «если это фиктивный компонент, используемый в тестировании: добавьте его в фиктивный модуль в этом файл согласно (этот URL)"

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

a) ИМХО, это практика DRY-кода для создания «вспомогательного» файла для размещения фиктивных компонентов, служб и т. д., которые используют все файлы .spec. Однако эта практика заставляет тестировщика столкнуться с этим сценарием ошибки.

b) Все файлы .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';

Надеюсь, это поможет кому-то.

Я думаю, что новый рендерер ivy решит несколько проблем с AOT. Как вы можете видеть из запросов на вытягивание и проблем, команда angular сосредоточена на ivy, поэтому нет смысла что-то делать с этой проблемой на angular 6.

Я думаю, что новый рендерер ivy решит несколько проблем с AOT.

Я люблю слышать это по каждому вопросу.

У меня также есть эта проблема с angular 7.2.0 и angular-cli 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 , должен быть включен в какой-то модуль. Независимо от того, импортируете ли вы класс компонента и объявляете его непосредственно в тестах или объявляете, например, в 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 , выдает ошибку: Неожиданное значение 'null' экспортируется модулем .

Это очень расстраивает.

@redplane Почему ты хочешь это сделать? Я имею в виду экспорт default .

Вот как они это делают сами:
https://github.com/angular/angular/blob/master/aio/content/examples/testing/src/testing/router-link-directive-stub.ts

Если я не import exported , почему Angular заботится о том, существует ли файл?

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

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

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

По этой причине компилятор angular хотел, чтобы мой библиотечный компонент был объявлен в любом из ngModules проекта приложения.

Чтобы решить эту ошибку, я должен объявить свои перечисления в файле public-api.ts , а также использовать их в проекте приложения с прямым импортом из библиотеки, а не с относительным путем импорта.

Например:
Имя проекта библиотеки: компоненты-lib
Название проекта приложения: демо-приложение

Чтобы использовать любые интерфейсы, классы, перечисления и т. д., объявленные внутри проекта библиотеки, импортируйте их с прямым путем:

импортировать {SearchEnum} из 'components-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!