Angular: Compilación Angular2 AOT: "No se puede determinar el módulo para la clase (... muchos componentes que no se usan)"

No se puede determinar el módulo para la clase.

El componente debe ser parte de un módulo. Está destinado.
Yo diría que es una solicitud de función.

@DzmitryShylovich Tiene sentido que los componentes que UTILICE debe ser parte de un módulo. Pero en lo que respecta al compilador, estos archivos no deberían importar. Son archivos .ts sin usar y sin referencia que contienen componentes.

@ swimmadude66 puede excluir archivos no utilizados en tsconfig

@DzmitryShylovich puedes, pero los archivos de barril complican eso. Si una clase se vuelve a exportar en un archivo de barril, también debo ignorar el archivo de barril, lo que puede causar problemas con las clases que SÍ necesito de ese barril.

Parece extraño que el compilador intente compilar más de lo absolutamente necesario. Dejando a un lado las sacudidas de árboles, esperaría que el compilador quisiera tratar solo con los archivos que se le dieron o vinculados explícitamente a archivos dados.

Parece extraño que el compilador intente compilar más de lo absolutamente necesario.

así es como funcionan los compiladores...

El hecho de que la compilación JIT funcione debería ser una buena evidencia de que el compilador NO NECESITA estos archivos. Está arrojando un error en lugar de una advertencia en los archivos que podrían excluirse sin causar daño.

puede hablar conmigo sobre cómo funcionan los compiladores todo el día, pero este es un problema real en un caso de uso algo básico. Solo pido alguna forma de al menos suprimir el error y continuar bajo mi propio riesgo.

Mi compañero de trabajo está intentando eliminar cualquier archivo de barril que podría estar impidiéndonos usar exclusiones generales, pero le pediría que revise el problema que abrí originalmente en @ngtools/webpack, donde otro usuario tuvo el mismo error de un componente al que solo se hace referencia en sus pruebas. https://github.com/angular/angular-cli/issues/3636

El compilador está al tanto de los archivos que no le pido que compile, y arroja errores irrecuperables para situaciones recuperables. así de claro.

No entiendo por qué tiene componentes en el mismo directorio que no están incluidos en el proyecto.
Creo que esto podría ser una solicitud de función, pero actualmente así es como funciona el compilador, y decir que "funciona en JIT" no es motivo suficiente para pensar que debería funcionar en AOT.
Lo que creo que debe hacer es separar estos archivos de su aplicación base en módulos y luego importarlos a través de algún tipo de administrador de paquetes, de esta manera resuelve sus problemas, ordena su directorio y facilita el mantenimiento desde todos los aspectos.

@Toxicable, los archivos no utilizados están en un módulo npm de estilo biblioteca. En general, el caso de uso ideal es algo como esto:

en @project/angular (nuestro módulo npm de código compartido) tenemos todos los componentes, conductos, directivas y servicios necesarios para crear nuestra aplicación base y comunicarnos con nuestra plataforma de back-end. Nuestros socios quieren una aplicación que se vea similar, pero use una página de inicio diferente o tenga algún componente nuevo agregado. Sin embargo, la mayoría de las demás páginas serán las mismas y todos los servicios necesarios para conectarse a nuestra plataforma podrían ser los mismos.

Nuestro enfoque para maximizar el código reutilizable fue hacer que cada socio creara módulos e importara una combinación de piezas nuevas y piezas compartidas del módulo npm. Mi nuevo HomeModule podría tener una importación como:

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

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

esto luego explota en AOT diciendo: Cannot determine the module for class OverviewComponent ya que no estamos usando el componente de descripción general de @project/angular.

Dado que literalmente ningún archivo apunta a @project/angular/components/home/overview/component.ts , no esperaría que al compilador le importara en absoluto que no se use. pero dado que el archivo existe dentro del directorio node_modules de nuestro proyecto, el compilador lo encuentra, se queja y muere.

¡En cuanto a los trabajos JIT! == AOT funciona, la aplicación base funciona con AOT, y los cambios en el socio de prueba de concepto son increíblemente pequeños. No pretendo dar a entender que todo lo que funciona en JIT debería funcionar en AOT, pero tengo muy buenas razones para creer que así debería ser.

Tengo otro ejemplo en el que este comportamiento actual no tiene sentido: las pruebas.
Digamos que tengo un directorio de funciones some-feature , con some-feature.component.ts y some-feature.component.spec.ts .
Este componente usa la proyección de contenido, por lo que me gustaría probar esa funcionalidad creando un componente de prueba dentro de mi archivo some-feature.component.spec.ts que usa el componente some-feature en la vista, así:

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

Luego uso este componente en mi módulo de prueba :

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

Todo es válido y excelente, hasta que ejecuto ng build --prod --aot usando angular-cli, que arroja:
Cannot determine the module for class TestAppComponent .

No creo que AOT deba preocuparse por los archivos .spec .

La regla general es: ngc compilará todo lo que compile tsc. E intentará compilar todos los componentes que encuentre. Sin embargo, Angular no puede compilar componentes sin un módulo relacionado.

Sin embargo, podríamos cambiar este error por una advertencia.

También tengo componentes de envoltura de prueba que se usan solo para probar y que hacen que AOT explote como se describe aquí. Sería bueno si AOT pudiera ignorar todos los componentes que satisfacen una expresión comodín como TestComponent*, etc.

Muy bien, entonces más información aquí. Parece que hemos encontrado una solución para nuestro caso (no soluciona el caso testWrapper). Parece que el verdadero problema en nuestro caso fueron nuestros archivos de barril. Al importar CUALQUIER COSA de un archivo de barril, sigue la cadena de todas las cosas reemitidas por los barriles. Dado que estábamos extrayendo nuestros componentes de un nivel superior PROJECT/components , estaba analizando TODOS los componentes en lugar de solo el que queríamos. Esto probablemente sería mejor como advertencia, pero puedo entender un poco mejor por qué el compilador se preocupó por esos componentes.

viendo el mismo error:

$ ./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 Fregadero de cocina: http://ng2.javascriptninja.io
y source@ https://github.com/born2net/Angular-kitchen-sink
Saludos,

sean

i18 no debe recorrer toda la estructura del proyecto y, en cambio, mirar las declaraciones utilizadas.

Traté de limpiar las directivas que no se están utilizando, y la madriguera del conejo se hizo más profunda:

$ ./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'.

permítanme agregar que todo funciona bien con angular-cli y angular-compiler, por lo que es solo i18 al que no le gusta mi proyecto.

Referencia (configuración agradable y limpia): https://github.com/born2net/ng-skeleton

Saludos,

sean

El mismo error para los componentes comentados... los componentes no utilizados y comentados para la etapa de desarrollo son solo un paso útil para no procesar

// two comments aot read:

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

@kirjai ngc compila todos los archivos dentro de un directorio fuente. no importa si lo importas o no.

@DzmitryShylovich , lo entiendo, solo digo que no creo que el AOT deba preocuparse en absoluto por este archivo en este caso ... en mi opinión, omitir los archivos .spec durante la compilación del AOT es el camino a seguir. Pero claramente hay algo que impide que el equipo haga eso, lo entiendo.

Como alternativa, entonces, ¿tal vez la guía de estilo no debería sugerir colocar archivos .spec en el mismo directorio que la entidad para la que se escriben las pruebas?

También me encuentro con este mensaje de error (y algunos otros) debido a nuestro código de prueba y AOT en combinación.

Puedo recomendar este artículo . Explica cómo se pueden provocar ciertos mensajes de error y cómo solucionarlos o solucionarlos.

Teniendo en cuenta que las personas se toparán con este problema exacto si siguen la guía de prueba oficial y crean su aplicación con AOT, es posible que desee actualizar la guía.

(Si alguien busca una respuesta con respecto a RouterLinkStubDirective )
_Puedes arreglarlo agregando un módulo "ficticio":_

/**
 * 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 {
}

Por cierto, también intenta determinar el módulo para las clases abstractas:
export abstract class AsyncTransform extends AsyncPipe implements PipeTransform { ... }

"Error: no se puede determinar el módulo para la clase AsyncTransform"

Agregarlo a un módulo tampoco funciona 😄.
"No se puede asignar un tipo de constructor abstracto a un tipo de constructor no abstracto".

esto está sucediendo para algunas clases también.

Err: no se puede determinar el módulo para la clase AppGlobalModalComponent

export class CustomGlobalModalComponent extends AppGlobalModalComponent {}

@gestj como señaló @Phmager , los módulos ficticios no son una solución para todos los casos. Además, son una solución bastante complicada, ya que terminas compilando código que no quieres ni necesitas.

Para nuestro caso, hemos parcheado el problema de una manera diferente. Movimos nuestros componentes compartidos a una biblioteca npm e ignoramos node_modules en nuestro tsConfig. Mencioné anteriormente que eso todavía no funciona, pero solo porque estábamos usando archivos de barril. Si apunta directamente a cada clase que necesita dentro de node_modules, ignorará a los demás. Sin embargo, tan pronto como apunta a un barril, arroja el error de los archivos no utilizados en el mismo barril.

Esto no es ideal, ya que mata todos nuestros maravillosos archivos de barril, pero al menos es predecible.

Todavía espero que este error sea degradado a una advertencia

Gran trabajo realizado en el equipo de Angular hasta ahora.
Estamos usando mucho Angular en nuestros proyectos y después de un año de tratar de entender todas estas cosas ruidosas de Angular2+, aquí está mi hallazgo:
1- Angular es masivo y lento, ¿quieres hacerlo rápido? use AOT y LazyLoading y gzip sus cosas.
2- ¿Quieres lazyLoad un componente? NO, podría cargar una ruta de forma diferida, por lo que si su aplicación es enorme pero solo una página, disfrute del tamaño del paquete de 8 mg.
3- ¿Quieres usar AOT? AOT tiene errores y es difícil de cumplir y no usa montones de características de javascript/es6 y probablemente reescriba mucho de su código.
4- ¿Estás usando AOT bien? Muy bien, ahora eche un vistazo a su paquete final, ahora es incluso más grande que @ angular/compiler más sus componentes no AOTed, bien hecho.

5-Como parte del beneficio de Angular2+, ahora eres elegible para usar gzip, en caso de que no supieras cómo usarlo antes, ahora que Angular es masivo, lo aprenderás mejor :) Así que ahí lo tienes, ellos estamos vendiendo gziping como una opción para optimizar el código Angular2 :)

@ xe4me Mantenga la discusión en este hilo relevante para el problema en cuestión, en lugar de solo una diatriba general contra el marco.

build:dev en https://github.com/AngularClass/angular2-webpack-starter convierte automáticamente una cadena en una matriz de cadenas para que coincida con una definición de función, build:aot muestra el error. Durante el desarrollo, parece que son necesarias compilaciones frecuentes de AOT.

Tengo el mismo problema y he encontrado una solución, tal vez también funcione para ti.

Mi escenario era el siguiente:

Tengo MapPipes.ts, que contiene dos tuberías.

Uno de los Pipes se usó en mi módulo, el otro no. Por lo tanto, no registré el segundo en la parte "declaración:" de mi decorador @NgModule . El problema le pasó a este segundo.

También registré esto (a pesar de que no se usó), y ahora funciona.

Mi sugerencia es cambiar el compilador angular de manera que intente encontrar módulos solo para las entidades angulares realmente utilizadas.

He estado recibiendo este error con una clase abstracta que extends NgClass . Eliminar la herencia parece solucionar este problema, pero obviamente crea otros problemas.

@DzmitryShylovich @kirjai esto es solo un problema con TestComponents en un archivo de especificaciones si los exporta. Y como normalmente solo deben usarse dentro del mismo archivo, no es necesario exportarlos. Problema resuelto para mí.

Honestamente, esto es ridículo, realmente no tengo nada más que decir al respecto aparte del hecho de que llevo muchas horas y todavía no puedo obtener algo que funcione bajo JIT trabajando con AOT (debo aclarar que este es solo uno de alrededor de media docena de problemas hasta ahora).

@cwmrowe está bien, pero ¿qué sucede si tiene uno que se está reutilizando en varios archivos de especificaciones? Esto parece roto para ser honesto.

En mi caso, estaba trabajando en 2 proyectos diferentes en la misma aplicación principal de Angular 2. Tengo 2 carpetas con el nombre de nuestros clientes, digamos some-domain.com y some-other-domain.com . La aplicación es exactamente la misma para los 2 proyectos y solo difiere un poco en el estilo y algunos componentes personalizados menores. Hoy necesito compilar la aplicación para el cliente A, y luego quiero compilar para el cliente B. En el código es tan fácil como cambiar 1 línea de código para mí:

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

Simplemente elimino el comentario del dominio que quiero compilar también y funciona.

Tenemos el mismo problema con la herencia y las clases abstractas y no encontramos ninguna solución. Tenemos algunos componentes que extienden un componente abstracto. En JIT todo funciona muy bien, pero en AOT no se pueden encontrar los módulos para componentes abstractos y no es posible declarar componentes abstractos en un módulo.

Actualmente no tenemos otra solución que no sea evitar los patrones de diseño de programación orientada a objetos y usar código redundante.

@jabaa elimina la anotación @Component de tu clase abstracta

@DzmitryShylovich Cuando elimino @Component el constructor no se hereda. Tengo que inyectar todos los inyectables en todos los componentes en lugar del componente abstracto. Eso es código redundante. Cuando cambio el constructor y los servicios de la clase abstracta, tengo que adaptar todos los componentes secundarios.

Actualmente solucionamos esto implementando todos los métodos abstractos con métodos ficticios y creando un módulo ficticio para todos los componentes abstractos. Pero alguien podría olvidarse de anular el método ficticio. Todo eso es solo un trabajo.

@jabaa ¿qué versión usas? el constructor se debe heredar independientemente de @Component .

@bigjetplane No estoy seguro de dónde está el problema, pero cuando elimino @Component aparece un error que indica que no se pudieron encontrar las dependencias del componente. Hasta donde yo sé, DI solo funciona para clases con decoradores angulares. Entonces, cuando elimino los decoradores, las dependencias no se inyectan. Usamos Angular 4.

@jabaa ¿se rompe con jit o aot, o ambos?

@bigjetplane Aquí está Plunker con el problema. Hay una clase abstracta con decorador y todo funciona en jit. Cuando elimina el decorador de la clase abstracta, la aplicación no se puede representar porque no se pueden cargar todas las dependencias: Can't resolve all parameters for App: (?).

Ese es nuestro caso de uso. Tenemos una clase abstracta con constructor e inyecciones. Solo queremos anular algunos métodos abstractos en los componentes secundarios.

El ejemplo dado no funciona en aot. La diferencia entre aot y jit es un gran problema para nosotros. Estamos desarrollando con jit. La compilación de producción es con aot. Así que estamos desarrollando una semana con jit sin errores ni advertencias y después de la semana queremos una compilación de producción y obtenemos muchos errores de la nada. Prefiero un interruptor para jit, donde puedo habilitar muchos errores. Una construcción jit necesita 10-20 segundos. Una construcción aot necesita 25 minutos.

@tbosch ¿ Alguna palabra sobre cambiar esto a una advertencia? Parece que desde mi última visita muchos otros han intervenido con sus propias anécdotas, y me preguntaba si podrías darnos una actualización.

¡Gracias!

También tengo el mismo problema.

En mi caso, estaba trabajando en 2 proyectos diferentes pero incluyendo los componentes comunes a través de un proyecto de biblioteca angular interno agregado como dependencia en package.json.

Como es un proyecto de biblioteca, los componentes no utilizados del repositorio de componentes arrojan el siguiente error al compilar una compilación de productos 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!

Parece que tengo que crear un módulo para cada componente y usar :(

Cualquier solución para este problema ayudará mucho.

También espero una solución a esto. Aparentemente, los desarrolladores de Angular pretenden usar componentes auxiliares para las pruebas, por lo que también debe ser posible excluirlos de la compilación de una manera limpia. Por ahora, estoy usando la solución sugerida por gestj (que define un módulo falso en el que se declara el componente stub).

Por lo tanto, cuando use componentes auxiliares para realizar pruebas, querrá nombrar su componente con el sufijo spec.ts como whatever.component.spec.ts . De esta manera, tsc ignorará estos archivos (dado que está excluido en su tsconfig) y, por lo tanto, ngc también lo ignorará.

EDITAR: resulta que este es un error diferente, resultado de un error en ngtools/webpack. Ese ticket se ha abierto aquí: https://github.com/angular/angular-cli/issues/6228

Nueva diversión en este frente para mi empresa. En un intento reciente de actualizar nuestros sistemas a v2.4.10, terminé con un par de docenas de errores de esta variedad:

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

Parece estar registrando todos los componentes en nuestra biblioteca compartida que no están siendo utilizados por la aplicación actual. Esto es inquietantemente similar al error por el cual abrí el ticket originalmente.

Sin embargo, no estoy seguro de qué más podemos hacer al respecto. Hemos intentado abordar cada componente que necesitamos de la biblioteca compartida directamente (sin usar ningún archivo index.ts , ya que parecían extraer todos los archivos a los que se hace referencia en el índice) y mover toda la biblioteca compartida a node_modules.

¿Por qué el compilador necesita conocer cada componente angular en mi carpeta node_modules ? Incluso si necesita leerlos para construir su mapa, ¡no debería importarle si tienen o no un módulo!

@swimadude66 , sí, nos encontramos con esto trabajando con nuestra biblioteca https://github.com/WealthBar/a2d3 . A pesar de que no proporciona componentes con plantilla (solo directivas), la biblioteca aún debe compilarse con el compilador AoT o no funcionará con compilaciones AoT cuando se use.

@chrisnicola ¿Está diciendo que la biblioteca debe compilarse previamente con AoT antes de publicarse? porque eso implicaría que la biblioteca tiene sus propios módulos, lo que parece realmente contrario a la intuición. Tal como está, la biblioteca son archivos ts sin compilar, que extraemos como cualquier otro archivo en nuestro proyecto. Luego, todo se compila con el complemento @ngtools/webpack para webpack.

Vale la pena señalar que incluso el error original de este ticket se "arregló" de nuestro lado hasta la versión 2.1.1 simplemente eliminando todas las referencias a los archivos index.ts. Esa solución ya no parece funcionar para v2.4.10.

Ah, ya veo, sí, leí mal tu problema. No está extrayendo una biblioteca compartida precompilada a través de NPM aquí, tiene una biblioteca TS local en su proyecto. ¿Entiendo bien ahora?

Estoy de acuerdo en que debería "simplemente funcionar" y tiene razón, definitivamente suena como el mismo problema donde encuentra componentes que no tienen ningún módulo en la aplicación. Una posible solución sería usar un tsconfig.json específico de compilación de AoT que excluya los archivos y las carpetas que no son necesarios para la compilación de AoT.

He logrado resolver todos nuestros problemas relacionados con este error.
El problema (y la solución) aparece al exportar.

Teníamos un componente que solo se usaba para pruebas. Se exportó desde otro archivo para poder reutilizarlo; esto provocó problemas al ejecutar nuestro objetivo i18n.

Para resolverlo, simplemente declaramos un módulo (asegúrese de exportarlo también):

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

Nuestro otro componente que causó un error fue un componente no utilizado que hackeó i18n.
Se estaba exportando para que la herramienta i18n lo recogiera, pero eso provocó el mismo error que el otro componente.

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

Nuevamente, usando la técnica IgnoreModule, podríamos omitirlo fácilmente.

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

@UtopianStorm eso no es una solución. Se mencionó anteriormente que tener un "UnusedModule" no solo es difícil de escalar, sino que también crea un módulo completo de archivos fuente que no debe incluirse en el paquete de distribución.

@Phmager ¿Alguna vez encontró una solución para el problema del componente abstracto? Estoy tirando de mi pelo.

@ swimmadude66 No es una solución en el sentido de que definitivamente es una solución alternativa, pero supera el error.
No estoy seguro de cuán difícil sería escalar ya que la técnica se puede aplicar cada vez que surge el problema.

Abarrotará su paquete de distribución, pero ¿importará eso? Por el estado de Angular, supuse que ya estaría lleno de nuestros archivos de especificaciones.
En cualquier caso, es un enfoque mucho más limpio que llegar directamente a las entrañas de la carpeta node_modules, ¿no le parece?

Al menos desde el caso de uso para el que originalmente abrí el ticket, ni siquiera es una solución viable. No es factible que todos los equipos asociados mantengan una lista de componentes compartidos no utilizados sobre la marcha.

Además, enviar esencialmente 2 aplicaciones completas simplemente porque el compilador es demasiado estricto es un compromiso que no estoy dispuesto a hacer. Angular ya es bastante grande, y no puedo justificar el envío de un módulo completo de componentes no utilizados solo para hacer feliz a su compilador obstinado.

@swimmadude66 Ya veo. Si cree que agregar otro módulo hace una gran diferencia, será mejor que lo mire nuevamente, porque no estaba abogando por crear solo un módulo sin usar para compartir para todo el proyecto, sino un módulo para cada componente que tenía que liberar. del compilador demasiado estricto - potencialmente dusins.

Vale la pena señalar que nuestra base de código compartida es bastante grande, por lo que un módulo sin usar sería, con mucho, el módulo más grande de la aplicación. Nuestra situación no es 100% típica, pero aún dentro de los límites de la razón para ser apoyada, creo.

Honestamente, después de 5 meses de ver que este ticket no va a ninguna parte, estamos buscando otras opciones, incluida la eliminación de nuestro repositorio de código compartido.

Me enfrento exactamente al mismo problema que tú, @swimmadude66 . El hecho de que esta no sea una advertencia suprimible es ridículo.

Estimado equipo de Angular, ¿hay algo que pueda hacer al respecto?

@DzmitryShylovich ¿Cómo excluyo un archivo mock.ts que no estoy usando? Intenté ponerlo en tsconfig.app.json , tsconfig.json y tsconfig.ng-cli.json y ninguno parecía funcionar.

Enfrentando el mismo problema con exactamente el mismo caso de uso: usamos Rollup, por lo que los componentes no utilizados ni siquiera llegan al paquete final.

¡Por favor, suprime esto! Es una gran molestia, y está deteniendo el trabajo.

Acabo de encontrarme con esto también, tan jodidamente frustrante.

@mlakmal y otros, que reciben un error en un código como

export class CustomGlobalModalComponent extends AppGlobalModalComponent {}

Elimine la anotación @Component de AppGlobalModalComponent o declare AppGlobalModalComponent (si es utilizable) en NgModule

Creé una directiva simulada para usarla en mis pruebas. Y obtenga este problema con la compilación AOT. No quiero importar esta directiva simulada en módulos simples. Por favor arregla esto.

Me pregunto si la etiqueta "freq1: baja" en este problema se debe al hecho de que AoT es un dolor de cabeza tan espectacular para que funcione, que la gente ni siquiera se molesta con eso. Es un poco increíble que un problema tan simple pero doloroso haya recibido esencialmente cero comentarios de los principales colaboradores de Angular.

De todos modos, hay una forma de excluir archivos que no se ha mencionado específicamente. Si tiene un patrón de nombres (por ejemplo .spec.ts , .abstract.ts , .stfu-aot.ts ), puede crear un archivo tsconfig.json separado para AoT y usarlo en su lugar: ngc -p tsconfig-aot.json . En este archivo, puede usar "exclude": ["./app/**/*.stfu-aot.ts"] para excluir los archivos. Es molesto, pero debería funcionar.

Editar: lo anterior no parece funcionar con las clases abstract que heredan de un componente. Hurra :(

Acabo de encontrarme con esto también, muy frustrante. Cuando se compila mucho, el componente común no se puede compartir en otra aplicación.

algunos de los casos comunes para este problema, evite agregar @Component a su clase de servicios:

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

Tengo un escenario en el que estoy inyectando un servicio en un servicio. A primera vista, parece algo fácil de implementar, solo agregue @Component. Por lo tanto, los documentos de Angular deben actualizarse para mostrar esta solución para servicios complejos: para resolver este problema, eliminé @Component. En el constructor del Servicio agregué:
constructor(@Inject(ExampleService) private exampleService: ExampleService)

no necesita agregar un decorador @Component() a ningún servicio. Solo @Injectable()

FWIW Tengo un MockXYZComponent que extiende XYZComponent un componente de aplicación pero solo se usa en especificaciones (tiene el mismo selector y, por lo tanto, no se puede importar a AppModule ).

¿No es este un caso de uso válido?

@alastair-todd no estoy seguro de entender lo que quieres decir. Si usa el componente como componente, entonces agrega el decorador @Component() . Si usa el componente como base, solo para heredar de él, pero no como componente, entonces no tiene que usar el decorador, sino simplemente heredar y usar el decorador en "sucesor".
Acerca de las pruebas unitarias: no puedo responder, ¿probablemente necesite crear un módulo de prueba especial? No hago pruebas unitarias en este momento.

@tytskyi Entendí que la herencia del decorador no era compatible. ¿Eso cambió recientemente?

el caso de uso es simular un subcomponente como se muestra a continuación. Ambos necesitan la directiva @Component para seleccionar el selector.

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

Sin embargo, eso genera el error de compilación OP AOT.

Mi punto es que este es un caso de uso válido, en cuyo caso la compilación AOT es demasiado entusiasta y/o ignora las especificaciones como parte del proyecto.

Tal vez mi solución ayude a alguien: acabo de crear un módulo ficticio que declara todo el componente simulado. Este módulo no es importado por nada, solo mantiene contento al compilador AoT. En consecuencia, ninguno de los componentes simulados es parte del código compilado. No es ideal, pero problema resuelto.

Me encantaría saber de alguna solución mejor.

Esto es tan extraño y vergonzoso que este problema se abrió en diciembre de 2016 y todavía tiene este problema. Convertí la estructura de toda mi aplicación para usar una compilación aot. Tengo 4 módulos con carga diferida y más de 60 componentes. El compilador solo se queja por solo un par de componentes (según lo que sugiere el error) que estoy seguro de que ya forman parte de las declaraciones de uno de los módulos con carga diferida, lo que me resulta un poco extraño.

Incluso da errores en componentes que ya forman parte de algún módulo.

Mismo problema

El compilador de Angular busca el conjunto de archivos que ha entregado a tsconfig, por lo que excluir archivos de allí debería excluirlos de esta verificación.

Esto es realmente molesto :(

@alastair-todd lo siento, perdí la notificación de tu pregunta en muchas otras notificaciones. Estás en lo correcto -
No se admite la herencia del decorador.

Ver respuesta de @robwormald

El compilador de Angular busca el conjunto de archivos que ha entregado a tsconfig, por lo que excluir archivos de allí debería excluirlos de esta verificación.

Entonces, podría intentar hacer convenciones para nombres de archivos simulados, como: selection-tool.component.mock.ts . Luego excluir a través de

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

Hice clic accidentalmente en el botón equivocado, ¡lo siento!

+8 meses y sigue siendo un problema. Mismo problema aquí ERROR in Cannot determine the module for class PasoFooterComponent

Creo que es vital que los desarrolladores de Angular ignoren estos archivos.

Si alguien puede darme consejos sobre dónde puedo encontrar este código, seré feliz.
para arreglarlo yo mismo. Esto es una molestia que es muy molesto. me topé con eso
otra vez ayer.

Si alguien piensa que esto es una característica y no un error, ¿qué tal si tenemos una bandera?
¿para esto?

El miércoles 9 de agosto de 2017 a las 2:40, Leonardo Vidal [email protected]
escribió:

+8 meses y sigue siendo un problema. Mismo problema aquí ERROR en Cannot
determinar el módulo para la clase PasoFooterComponent

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/angular/angular/issues/13590#issuecomment-321082545 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEM6r7FOTLcicWJN3Oijw2pwKTLGL6cFks5sWM61gaJpZM4LSAwS
.

@samirotiv ¿Tienes alguna reproducción?
Como dijo @robwormald

El compilador de Angular busca el conjunto de archivos que ha entregado a tsconfig, por lo que excluir archivos de allí debería excluirlos de esta verificación.

Tuve el mismo problema pero logré resolverlo. Acabo de ver cómo ts transpila mi aplicación, por ejemplo

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

Y me di cuenta de que mecanografiado no compiló mis módulos cargados de forma diferida porque usé la opción tsconfig de "archivos"

Recibo este error en la clase abstracta (sin decoradores)

Comencé a encontrarme con este mismo problema recientemente.

+1 para cambiar error a advertencia.

Parece una solución fácil. ¿Por qué la demora?

Este es un requisito básico: deje los archivos sin referencia.
Esta restricción es un problema para proyectos más grandes. Cambie esto a advertencia.

Hay casos en los que publica un paquete que admite diferentes versiones de angular. y se espera que el usuario elija uno de ellos.

Por ejemplo, un paquete que proporciona archivos para HttpClient (Angular >= 4.3 usuarios) y Http (Angular <4.3 usuarios)

Actualmente, ngc compila todos los archivos dentro de un directorio fuente sin importar si los usa o no. o la compilación falla.

Lo que hice fue esto:

Guardé todos mis componentes stub/simulacros con una extensión .mock.ts y actualicé la matriz de "exclusión" tsconfig.app.json de la siguiente manera:

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

AOT ahora omite la compilación de estos archivos

Estamos haciendo una biblioteca npm con componentes comunes que se supone que no deben usarse todos a la vez y molestos por ese problema durante la compilación de AoT, maldita sea ... La única solución atm es crear una especie de UnusedComponentsModule en el proyecto host, ¡simplemente ridículo! También necesita NO_ERRORS_SCHEMA o jurará sobre otros componentes que se pueden usar dentro de sus componentes no utilizados y, si los declara, entonces encontrará otro problema en el que no puede declarar el mismo componente en dos módulos (relacionado con # 10646).

Mi módulo actual:

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 {
}

Esto realmente debería ser una advertencia. También estoy tratando de compartir una base de código y me encuentro con este problema de componentes que no forman parte de un ngmodule.
El problema aquí está exactamente a la par con una variable no utilizada que no es un error; a lo sumo es una advertencia.

Es fácil cuando es su código. Cuando se trata de un problema de alguna biblioteca angular NPM (algún código muerto), entonces es realmente un dolor en el culo :)

¿Alguien puede explicar por qué no puede ser una advertencia en lugar de un error?

En mi caso, solo quiero extraer langs preferiblemente de los componentes que están conectados a ngModule e ignorar aquellos que no lo están. Tengo una carpeta principal de la aplicación con componentes base y carpetas específicas de la aplicación que a veces anulan los componentes de la aplicación principal cuando intento extraer dicho componente anulado con xi18n, arroja un error Cannot determine the module for class... que, en mi opinión, podría simplemente ignorarse y extraerse podría continuar sin usar ese componente no utilizado.

Una cosa que se me ocurre que podría ser un problema es que todavía uso esa clase que está definida en ese archivo de componente defectuoso como base para crear el componente anulado, por lo que debe compilarse, pero simplemente no necesito ese componente. causa de la anotación ya que no puede usarla en el componente anulado. Al menos creo que no puedes porque tengo que recrear esas anotaciones en componentes derivados para que funcionen.

@Xesenix al menos debería ser una opción. Como determineModule = false / true. Ahora son plátanos.

Volveré el 1/11/2017.

Responderé a su mensaje después de mi regreso.
En casos urgentes, envíe una copia de su correo electrónico para
asuntos técnicos a [email protected] , de lo contrario a
[email protected]. Otro empleado luego mirará su correo electrónico.
aceptar.

Nota: Esta es una respuesta automática a su "Re:
[angular/angular] Angular2 AOT compilación - "No se puede determinar el módulo
para la clase (... muchos componentes que no se usan)" (#13590)" enviado el
23/10/2017 08:13:17.

Esta es la única notificación que recibirá mientras
esa persona está ausente.

¿Cómo es que esto todavía no está arreglado casi 1 año después? Tirarme de los pelos para que AOT funcione, pero este problema me hace chocar contra una pared.

¡Gracias @rahul-sivalenka-wtc por la solución!
Pude resolver mi problema con éxito al excluir "**/*.mock.ts" en mi tsconfig.app.json como usted describe ❤️

Me alegro de poder ayudar 😊

También me he encontrado con el problema. Pero para mí, parece que simplemente puse mal la ruta de importación de dodule.

¿alguna solución? (no se puede determinar el módulo para el componente angular 5)

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

Esto probablemente debería ser severity3: broken . Para aquellos de nosotros con múltiples objetivos de compilación y dependencias polimórficas (muchos de los casos de uso se han presentado anteriormente), este problema impide que las compilaciones funcionen sin una configuración de compilación complicada y loca.

alguna buena solución para este problema todavía? IgnoreModule es solo una solución alternativa, pero no una solución realmente buena para este problema. ¡cambiar el error a una advertencia sería genial!

Nuestra solución fue agregar una función transform a @ngtools/webpack que pasa archivos a través del preprocesamiento y ifdef componentes de procesamiento basados ​​en varias configuraciones de tiempo de compilación. Muy, muy feo, pero funcional.

Intente importar todas las dependencias angulares primero en app.module.ts y luego importe los componentes.

` ---------------- Primeros módulos de dependencia de importación -----------------------
importar {ModuloNavegador} desde '@angular/plataforma-navegador';
importar { CommonModule } desde "@angular/common";
importar {NgModule} desde '@angular/core';
import { RouterModule, Routes } from '@angular/router';
importar {HttpModule} desde '@angular/http';
importar { ReactiveFormsModule } desde '@angular/forms';
import { BrowserAnimationsModule } from '@angular/platform-browser/animations';

-------------Luego Importar módulos de servicio ------------------------

import { ApplyFormPostService } from './Services/apply-form-post.service';
importar { NavBarColorService } desde './Services/nav-bar-color.service';

----------------------- Finalmente importar módulos de componentes ----------------------- -

importar {AppComponent} desde './app.component';
importar {HeaderComponent} desde './components/header/header.component';
import { CareerComponent } from './components/career/career.component';
importar { HomeComponent } desde './Components/home/home.component';`

De alguna manera, esto resolvió el error de compilación AOT arrojando No se puede determinar el módulo para la clase --- en modo de producción

@KarthikSamyak , este problema no se trata de personas que tienen clases que DEBERÍAN estar en un módulo. Se trata de aquellos de nosotros con bibliotecas de componentes, que se excluyen deliberadamente de todos los módulos. Son código no utilizado que el compilador debe ignorar. En cambio, el compilador lanza un error irrecuperable cuando los descubre.

Realmente debería ser un cambio simple convertir este error en una advertencia, pero por alguna razón ha tardado MÁS DE UN AÑO y recientemente se ha movido de pri_col1 a pri_col2 en la hoja de ruta.

Estoy cada vez más frustrado con el equipo de Angular por su completa falta de respuesta a este problema. Nuestra empresa finalmente renunció a usar bibliotecas de componentes por completo y optó por copiar los archivos manualmente. Esto está lejos de ser ideal, ya que ahora tenemos problemas con componentes casi idénticos, pero no compartidos.

Equipo de Angular, si sigue leyendo este problema, simplemente agregue una configuración de compilador para "ignoreUnusedComponents" y sigamos usando este marco.

Ok, encontré el lugar https://github.com/angular/angular/blob/master/packages/compiler/src/aot/compiler.ts#L605 @tbosch oye, ¿puedes ayudar aquí y decir cómo hacer eso? ser una advertencia correctamente? No puedo ver ninguna advertencia arrojada en ese compilador AoT, solo errores. Se puede agregar la opción del compilador, como se sugirió anteriormente.

Ese problema es un dolor en proyectos complejos. Mi caso particular es https://github.com/angular/angular/issues/13590#issuecomment -331820496

Nuestro caso de uso es el mismo. Queremos tener una biblioteca de módulos/componentes para crear aplicaciones realmente fáciles y tener la capacidad de reemplazar/ampliar las extrañas cuando sea necesario.

También tenemos problemas en el otro sentido: si queremos reemplazar el componente 1x dentro de un módulo, creamos un nuevo módulo e importamos los componentes que todavía queremos allí:

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 { }

El error es: `HeaderComponent se declara en 2 módulos: lib/module.ts y app/module.ts
Ser una advertencia en cambio al menos nos permitiría avanzar :(

Me acabo de dar cuenta - Feliz cumpleaños a este problema :)

Un año después, TODAVÍA no podemos cambiar esto a una advertencia. Ridículo.

Literalmente, también me encontré con este problema. El compilador intenta obtener un simulacro que solo se usa en las pruebas y falla porque no es parte del módulo principal. Si sabe que no necesita el archivo, debería ser una advertencia como máximo.

Por favor arregla esto. ¡Conviértelo en una advertencia!
Mi experiencia general con la construcción angular 5 aot es menos que estelar.

Después de un debate https://gitter.im/angular/angular?at=5a551f565a9ebe4f756843b2 , llegamos a la conclusión de que necesitamos crear un Componente por módulo, ya que parece que el módulo es solo un contexto de compilación y no una forma de recopilar cosas. .

Esto está tomando el tamaño de un libro de historia.

@Xesenix ... el contexto y la organización son 2 partes del todo.

En caso de que alguien todavía esté atascado con esto, puede hacer que este script se ejecute como script posterior a la instalación como solución alternativa

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);
    }
});

El compilador angular usará la salida de tsconfig, así que cambie _tsconfig.app.json_ para excluir aquellos archivos que no desea incluir.
p.ej
"exclude": [ "test.ts", "**/*.spec.ts", "**/*.mock.component.ts", ]

@andela-andrewmakenzi esto ha sido sugerido antes, más arriba en este gigantesco chat (absolutamente no es ninguna vergüenza no leerlo todo). Sin embargo, surgen problemas si depende de un componente en una biblioteca que usa archivos de barril (index.ts). Si importa cualquier componente de un archivo de barril, el compilador intenta cargar todos los componentes a los que se hace referencia en ese archivo de barril y se quejará de que no están en un módulo. Esto hace que sea difícil empaquetar bibliotecas de componentes reutilizables, que es básicamente el punto central de la arquitectura de componentes en primer lugar.

Su solución funciona muy bien para las personas que tienen componentes simulados y obtienen este error cuando no están ejecutando pruebas. Pero si su organización (como la mía) intentó crear una biblioteca de componentes comunes e incorporar solo los que necesitamos para un proyecto determinado, la exclusión de TSC lamentablemente no lo ayudará.

@andela-andrewmakenzi: su sugerencia parece ayudar por ahora, el problema anterior es que tengo un componente para prueba unitaria como (.spec) y no me gustaría que se incluyera para AOT-build (y tal vez algún componente simulado que Ni siquiera me gustaría tenerlo en mi proyección) Tal vez esto se solucionó de alguna manera en una versión posterior de Angular, creo :)

Pero mi caso fue que tengo muchos componentes nuevos a los que ni siquiera se hizo referencia en NgModule, por lo que por ahora debemos tener una convención de nombres para ellos y excluirlos en tsconfig.json, lo cual no es muy agradable por el momento.

Esto es realmente ridículo. Tenemos un módulo NPM compartido que exporta un par de conductos/directivas y, a menos que importe TODO, falla con este error tonto. Realmente debería cambiarse a una advertencia y no debería interrumpir la compilación.

En mi opinión, cada componente debe estar en su propio NgModule . No da tanto miedo crear otro NgModule para cada componente. (Como lo que hizo @angular/material )

Creo que es realmente un problema virtual. Tampoco podemos ver ninguna razón por la cual tener algo a mitad de camino. No es un NgModule , no es un paquete, no está fuera del árbol de la aplicación... algo que parece un código inactivo.

Entonces, con el nuevo @ angular/cli (1.7.0+), incluso IgnoreModule de alguna manera no soluciona este problema.

En mi opinión, cada componente debería estar en su propio NgModule

¿Incluso tratas de escribir pruebas unitarias? Este error hace que la creación de ayudantes de prueba sea un poco problemática.

@sarunint En aplicaciones de tamaño empresarial como para la que originalmente abrí este ticket, serían cientos de módulos, con importaciones muy complicadas para manejar componentes y directivas dependientes. Esto tiene una solución muy simple: si el compilador no puede encontrar un módulo para un componente, lanza una advertencia y deshazte de él mediante la sacudida del árbol.

La verdadera razón por la que esto es tan molesto es el hecho de que las limas de barril se vuelven más un peligro que una bendición. Es conveniente centralizar sus importaciones, pero no si se compromete a incluir todos los componentes exportados en cada aplicación que usa su biblioteca.

@dborisenkowork No estoy seguro de si no lo vio (o si no funciona para su caso de uso), pero la solución proporcionada por @rahul-sivalenka-wtc funciona perfectamente.

¿Alguien se ha mudado recientemente de angular 4 a angular 5 y notó que algunos de sus componentes que en realidad se declaran en módulos arrojan este error?

@novologic-clay ¿qué error? El hilo es largo, te refieres al error original
Compilación Angular2 AOT: "¿No se puede determinar el módulo para la clase (... muchos componentes que no se usan)" ?

@andela-andrewmakenzi Sí y no. Es el mismo error que aparece al intentar compilar, pero el componente del que se queja seguramente está incluido en un módulo. Estoy migrando de 4.3.6 a 5.2.4, y no recibí este error para este componente en particular porque actualicé mi versión de angular e hice una compilación AOT en 4.3.6 justo antes de comenzar a migrar como prueba de humo .

@novologic-clay, ¿puede compartir los errores de su consola?

... el objetivo final debe ser usar la opción $ tsconfig.json "noUnusedLocals": true que elimina todo lo que no se usa.

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

Esta es una aplicación empresarial y hay docenas de capas de módulos e importaciones, pero este es el código que realmente declara el componente:

**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 { }

También cabe destacar que cuando ejecuto esta aplicación en ng serve, el componente funciona bien.

Los componentes falsos utilizados por las pruebas de muchos componentes reales no deben estar en un módulo; Solo se incluyen en TestBed de componentes probados.
Este error es estúpido. Resuelva eso tal como está durante un año.

elimine la "exportación" para que ts no la lleve a la compilación.

@ tony-kaplan No puede hacer eso si no tiene UnusedLocals en su tsconfig, ni si desea usar el código en casos de prueba o similar.

Dios mío... ¿realmente nadie del equipo central encontró una solución adecuada para esto?
Estoy usando la opción exclude por ahora, pero aún así es una solución temporal. No puedo pensar en algo que funcione para todas las situaciones... pero realmente lo necesito...

@gabrielalan La solución fácil es convertir este error en una advertencia. La mejor solución es agregar una bandera que le permita tratar esto como una advertencia o un error. No es la falta de soluciones, es la falta de implementar cualquiera de ellas.

¡Oh chico! Demasiado para un marco empresarial...

@ atom-morgan ¿de qué solución estás hablando?

@netlander Este

Realmente, ¿no puedo hacer nada con respecto al error "No se puede determinar el módulo para la clase DaterangepickerDirective"?

¿Alguien me ayuda también? ¡Después de esta publicación megazord!

¡No acepto agregar las nuevas exclusiones de tsconfig.app.json a esta directiva! ¿Cómo puedo compilar con --aot param sin este problema?

Mi caso de uso https://github.com/angular/angular/issues/23475
Estoy creando una biblioteca de validadores y no quiero crear un módulo para cada directiva de validador, todo lo que quiero es poder agrupar directivas de validador en el paquete npm para que el usuario pueda instalar e importar solo los validadores que necesita para NgModule. Además, no quiero crear un módulo para todos los validadores porque todos se incluirán en el paquete final, lo que es una gran pérdida de tamaño.

Estoy feliz de crear relaciones públicas para solucionar el problema.

@anjmao eso es increíblemente similar a la razón por la que abrí esto en primer lugar. Como solución alternativa para una biblioteca pequeña, descubrimos que este error no ocurre si no usa archivos barril (index.ts). Parece que si importa 1 componente/directiva de un índice, intenta encontrar un módulo para todas las demás exportaciones del archivo de índice.

Obviamente sigo creyendo que esto debería ser una advertencia, ya que los archivos de barril son muy convenientes. Sin embargo, si su caso de uso no puede esperar otro año para esta solución, es posible que pueda solucionarlo de esa manera.

Solución alternativa que estoy usando para mi biblioteca compartida de componentes/directivas/tuberías: cree un módulo ficticio simple que haga referencia a todas las declaraciones de clase. No necesita usar este módulo en sus aplicaciones reales, solo tiene que existir en el disco. Ex:

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

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

¿Hay alguna razón por la que todavía no hemos solucionado este problema?

¿La solución "Que sea una advertencia" no es adecuada? ¿Puede un miembro del equipo central comentar sobre esto?

En mi caso, las cosas estuvieron bien con NG 5, CLI y AOT. Pero después de actualizar a NG 6, recibo un error similar para un componente no utilizado. En realidad el componente se utiliza a través de un servicio inyectado al otro componente. Tengo muchos componentes similares construidos y usados ​​de la misma manera. Pero solo uno tiene el problema uno al actualizar a la última NG CLI 6.0 y 6.0.1

Y resultó que, en una de las referencias, tengo la referencia del archivo en el caso incorrecto. Tengo un index.ts para exportar todos los componentes en el mismo directorio. tuve
export * from './dateTimePicker.component'
mientras que debería haber sido:
exportar * desde './datetimePicker.component';

Aparentemente, NG CLI 6 está más restringido para carcasas incluso en Windows, mientras que NG CLI 1.x es un poco relajante.
Obviamente, dicha restricción es buena y correcta, por lo que el mismo código base podría funcionar bien en Linux, que distingue entre mayúsculas y minúsculas de forma predeterminada.

Otro caso de uso para esto:

Typescript le permite configurar varias rutas de resolución con la variable paths en tsconfig.json . Ex:

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

Permitiéndote importar cosas como esta:

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

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

Si está generando un componente dentro src-gen que el desarrollador puede "anular" creando otro dentro de la carpeta src , el mismo error comienza a ocurrir con el componente (ahora sin usar) dentro src-gen (que no debería ser necesario eliminar, ya que el anulador podría extenderlo).

Otro caso de uso potencial:

Componentes específicos del entorno. Los despojo para la producción.

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

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

Logré que todo lo demás funcionara con componentes específicos del entorno y esto es lo que me detiene. 😪

Nos enfrentamos a este problema cuando implementamos un mecanismo para la personalización de la compilación (los componentes se intercambian por diferentes proyectos de Angular CLI) que se parece bastante al escenario descrito por @tiagodws (incluida la extensión del componente original).

¿Hay alguna actualización/opinión de un equipo central sobre este tema?

Más de un año después de abrir este número, mi nuevo enfoque es minimizar el uso de archivos de barril. Si usa rutas TS como ~components/button/component en sus importaciones en todas partes, las importaciones no utilizadas se ignoran. Si se hace referencia a ese componente no utilizado en un archivo de barril, se lanzará.

Eso todavía no es sorprendente para las bibliotecas reutilizables, ya que debe acceder a todos los componentes de la biblioteca con rutas más largas, en lugar de solo importar desde el nivel superior de esa biblioteca. ¿Por qué, oh, por qué esto no puede ser solo una advertencia?

Esto también parece que podría ser ayudado por (o al menos relacionado con) el movimiento del árbol, donde cualquier código que no esté incluido específicamente en un módulo se excluye del paquete final.

La opción de exclusión no es para una tubería simulada:

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

Mi tsconfig.app.json ha excluido este archivo:

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

Sin embargo, cuando ejecuto ng-xi18n --i18nFormat=xlf2 --outFile=./assets/i18n/messages.xlf, todavía se queja:

¡No se puede determinar el módulo para la clase MockTranslatePipe en src/test/translate.service.mock.ts! Agregue MockTranslatePipe al NgModule para solucionarlo.

Mi problema fue que tenia el nombre de una clase en 2 componentes diferente por copiar y pegar jajaja! Después mismo error por no importar ¡Las buenas prácticas hacen al maestro muchachos! éxitos ...
Firma: Satoshi Nakamoto :v

Similar a @yuezhizizhang , todavía tengo este problema, incluso después de agregar un glob para simulacros a la ruta tsconfig.app.json exclude .

Está al borde de la indignación que esto no se haya resuelto casi dos años después de la multa inicial; este es un caso de uso común que está ROMPIENDO compilaciones. Al escribir pruebas, el desarrollador idealmente debería crear simulacros para tuberías, servicios, etc., a menos que. Si elige hacer esto, su compilación se rompe. De lo contrario, sus archivos de especificaciones hacen referencia a los componentes/tuberías/etc. reales, lo que conduce a pruebas muy estrechamente acopladas.

¿Podría alguien del equipo de Angular sugerir cómo solucionar esto? ¿La creación de un módulo ficticio comodín para simulacros es realmente la única opción? Ese es un truco pobre, en lugar de algo que deberíamos aceptar como la mejor práctica.

el problema persiste. También agregué el archivo que deseo omitir la compilación (clase abstracta) a la sección de exclusión de tsconfig.app.json y sigo recibiendo:

¡No se puede determinar el módulo para la clase MapElementBaseComponent en .../map-elements/map-element-base.component.ts! Agregue MapElementBaseComponent al NgModule para solucionarlo.

Me deshice de este problema después de verificar dos veces las importaciones.

14 de noviembre. 2018 julio, 15:13 Daniel Groh [email protected] :

el problema persiste. También agregué el archivo que deseo omitir la compilación
(clase abstracta) a la sección de exclusión de tsconfig.app.json y yo
todavía obtener:

No se puede determinar el módulo para la clase MapElementBaseComponent en
.../mapa-elementos/mapa-elemento-base.component.ts! Agregar MapElementBaseComponent
al NgModule para arreglarlo.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/angular/angular/issues/13590#issuecomment-438641324 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AQb6kpWdkakUF8JVvea8Hy42tAnTKTuzks5uvAjvgaJpZM4LSAwS
.

Cuando TypeScript es estricto, la importación de Angular, en la compilación AOT, no se usan componentes de una biblioteca y se lanza este error... Verificar componentes/módulos no usados ​​no tiene sentido...

Al eliminar la carpeta de la biblioteca donde se encuentran el módulo y los componentes no utilizados, la aplicación se inicia de forma estricta, muy bien, pero seguramente no tiene sentido eliminar esta carpeta manualmente.

Este error es absolutamente ridículo. Tenía un módulo que especificaba componentes en un objeto, así:

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

luego traté de alimentar el módulo con declarations: Object.values(landingComponents) , entryComponents: Object.values(landingComponents) .

Adivina qué... el compilador AOT necesita ver los componentes enumerados en una matriz... de lo contrario, si lo paso de otra manera, aparece este horrible "No se puede determinar el módulo para la clase".

Por mucho que ame Angular, el compilador AOT parece una sopa caótica de encantamientos mágicos.

Se ha dicho un par de veces, pero la solución es 1 componente por Módulo para esto y no estoy seguro de si se dio cuenta de los PR a Angular, pero esto se fusionó recientemente y podría ser de interés para este tema: https://github.com/ angular/angular/tirar/27481

Este número cumple hoy 2 años 🎉

Aún así, ni siquiera una palabra del equipo central sobre por qué esto no podría ser solo una advertencia.

@tiagodws lol ¿cuánto tiempo has estado esperando para publicar esto? ¿Configuró un recordatorio?

Solo un FYI
Mi problema era el mismo que https://github.com/angular/angular/issues/13590#issuecomment -389113560
Las importaciones aparentemente distinguen entre mayúsculas y minúsculas en el modo AOT

@peterdeme ... JavaScript distingue entre mayúsculas y minúsculas (y las rutas como cadenas son iguales ... = basado en Linux, no en Windows).

Hola chicos, acabo de regresar para una celebración tardía de la edad de emisión de 2 años. Hay muchas conversaciones cruzadas sobre las posibles causas para las personas, incluidas las secciones include y exclude de tsconfig.json , por lo que solo quiero aclarar cuál es la raíz del problema. para este hilo.

Si crea una biblioteca de componentes reutilizables y agrega archivos de barril ( index.ts ) para facilitar las importaciones, entonces el compilador angular se romperá cuando use cualquiera de ellos. Esto se debe a que tan pronto como importe algo de ese archivo de barril (por ejemplo, @shared/components ), intentará encontrar el módulo para CADA ÚNICO COMPONENTE. Incluso si especifica los componentes específicos que desea (por ejemplo import { SharedToastComponent } from '@shared/components'; ), el compilador buscará el módulo para todos y cada uno de los componentes exportados y arrojará un error (no una advertencia) sobre los componentes que faltan.

Obviamente, hay soluciones.

1. Deja de usar limas de barril. Esto se complica rápidamente, ya que cada componente debe especificarse por completo.
2. Use un ExtrasModule y no use el módulo en ninguna parte. Esto funciona bien para las personas que tienen componentes que solo se necesitan para las pruebas, pero no tan bien para las personas que buscan extraer de una biblioteca de componentes.

Sin embargo, dado que el uso de cualquiera de estas soluciones da como resultado exactamente el mismo código de salida después de la sacudida del árbol, es obvio que los otros componentes NO NECESITAN incluirse en un módulo usado. Todo lo que pido con este problema de 2 años es convertir ese error en una advertencia más apropiada. Tiene sentido, ya que la compilación aún tendría éxito si se le permitiera continuar.

Esperamos que en 2019 el equipo de Angular haga algo con respecto a este problema muy antiguo y molesto. 🤞

@ swimmadude66 ... no mencionó la forma de crear un módulo lib real y agregarlo a una aplicación Angular a través tsconfig.json ... como: "paths": {"ng-demo": ["./packages/ng-demo/src/index.ts"]} y usarlo a través de importación como import { DemoModule } from 'ng-demo'; . De esta forma, se elimina la necesidad de publicar la lib en un repositorio npm público/privado, pero aún así se respeta el rol nativo de ese módulo lib. Entonces funciona de forma transparente en su aplicación y no tiene ningún problema.

Tener un error en el resguardo de cada componente es lo más molesto. Todo el mundo está probando/escribiendo especificaciones, ¿verdad? Por lo tanto, los errores de código auxiliar del componente deberían afectar a todos. No digo que el tema del cañón sea menos molesto. Solo digo que no todo el mundo está haciendo los barriles. Pero todo el mundo debería estar haciendo especificaciones. Entonces, el problema de las especificaciones debería ser la mayor motivación para que el equipo central solucione esto. Actualmente está etiquetado como "Frecuencia baja", pero debería ser "Frecuencia alta" porque cualquier persona que realice pruebas unitarias encontrará este problema.

Esto ni siquiera es consistente en AOT. Angular CLI no da errores cuando se ejecuta con el servicio (que de forma predeterminada usa AOT), pero sí da errores cuando se ejecuta con build.

Entiendo que este no es el repositorio CLI angular, pero ciertamente el comportamiento que lo rodea es extraño.

Incluso con la solución alternativa de crear un módulo simulado, ahora la "compilación ng" fallará si un escritor de prueba de unidad de interfaz de usuario se olvida de agregar un solo componente simulado a un módulo simulado.

Lo anterior significa que las pruebas unitarias de la interfaz de usuario son actualmente un elemento de riesgo para la canalización de implementación de CI/CD.

¿Realmente queremos tener que explicar a las personas más altas en la cadena alimenticia que los probadores de unidades angulares pueden romper compilaciones de implementación completas con una sola omisión trivial? No. Las personas que administran desarrolladores de Angular y que toman decisiones sobre qué marco usar para el próximo proyecto no deberían preguntarse sobre este tipo de cosas.

Como solución provisional: ¿por qué no simplemente hacer que el error que aparece en "ng build" sea más informativo para los redactores de pruebas? Es decir, agregue texto adicional con el efecto de "si este es un componente simulado utilizado en las pruebas: agréguelo a un módulo simulado en ese archivo según (esta url)"

Cómo llegaron aquí las pruebas unitarias de escritura de desarrollo Angular promedio amigables:

a) En mi humilde opinión, es una práctica de código DRY crear un archivo de "ayuda" para colocar componentes, servicios, etc. simulados que usan todos los archivos .spec. Sin embargo, esta práctica ejecuta al probador justo en este escenario de errores.

b) Todos los archivos .spec pueden importar este archivo "auxiliar" sin necesidad de un "módulo simulado" que no tiene relevancia para el código de prueba real. Los componentes simulados son útiles tal como están, sin membresía en un módulo simulado que no tiene ninguna función en el entorno de prueba de una especificación.

Seguro que la solución es trivial... pero simplemente encontrar este error a través de la búsqueda de Google, leer y digerir el hilo y las soluciones útiles no lo fueron.

Solo agrego esto al final del archivo auxiliar que contiene los componentes simulados (entre otras cosas):

/*
  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 {}

Tenga en cuenta que el archivo anterior en realidad es bastante grande... el "MockTestModule" está enterrado al final del archivo auxiliar...

...Espero que no tengamos que escribir una entrada de package.json para "ng build" que intercepte la llamada e inserte un mensaje de consola "hey probadores de unidades de UI, ¿agregaron su componente simulado al módulo simulado?" empujar.

Esto es lo que resolvió el problema para mí. Mi estructura es la siguiente:

├── 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

En icons.module.ts tenía:

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 {}

Los index.ts tenían:

export * from './icons.module';

Asumo que el problema era que el compilador no había analizado los módulos icon e icon-indicator antes de encontrar los componentes correspondientes y, por lo tanto, arrojó el error Cannot determine the module for class . Este proyecto es ng 5. Solo recibí el error cuando lo consumí en un proyecto ng 7.

La solución es mover las exportaciones un nivel hacia abajo. Así que eliminé la declaración de exportación en icons.module.ts y los moví a:

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

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

y ajustado index.ts :

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

Espero que esto ayude a alguien.

Creo que el nuevo renderizador ivy resolverá bastantes problemas con AOT. Como puede ver en las solicitudes de extracción y los problemas, el equipo angular se está enfocando en ivy, por lo que no tiene sentido hacer algo sobre este problema en angular 6.

Creo que el nuevo renderizador ivy resolverá bastantes problemas con AOT.

Me encanta escuchar esto en cada tema.

También tengo este problema con angular 7.2.0 y 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.

Por ejemplo, tengo un TranslatePipe y un TranslatePipeMock dentro de mi Shared Module . TranslatePipe está incluido en el módulo, la tubería simulada no lo está.
translate.pipe.mock.ts es para fines de prueba unitaria, por lo que puedo importar este archivo a cada prueba unitaria.

Pero ahora mi compilación falla
ng build --prod

¿Cómo arreglamos esto?

Atm tengo una solución que lo resuelve

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

Es difícil determinar el estado actual de este problema a partir de un breve recorrido por los comentarios. Estoy de acuerdo en que esto es un problema (mal diseño). ¿Cuál es el plan para solucionarlo? ¿Es fácil o difícil?

@rrmayer , lo más probable es que el estado de este problema sea simplemente "esperar a ivy", como ocurre con casi todos los problemas "actuales".

Solo queremos que esto cambie de "error" a "advertencia", para que nuestros proyectos realmente se compilen... ¿Es tan difícil?

@ Terrafire123 ... podría haber muchas relaciones con las herramientas de prueba o construcción, por ejemplo, que se basan en el hecho de que este caso conduce al error, por lo que el cambio en la advertencia podría ser un problema grave.

No tengo ninguna esperanza de que se arregle para el compilador actual: D

Tal vez al menos deberíamos tener la opción de mostrar un error o una advertencia. Las compilaciones que se rompen debido a que los componentes no forman parte de un módulo a propósito son bastante molestas.

Las importaciones no utilizadas pueden causar este error.

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

Parece que la palabra clave 'exportar' junto a la clase determina de alguna manera que la clase a la que se aplica el decorador @Component debe incluirse en algún módulo. Ya sea que importe la clase del componente y la declare directamente en las pruebas o la declare, por ejemplo, en CoreMocksModule y luego importe el módulo, todo no importa.

¡Sin embargo, hay una solución! Digamos que tenemos nuestro componente stub declarado así:

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

Tenemos que eliminar la palabra clave 'exportar' pero de alguna manera todavía tenemos que exportar el componente para usarlo en el módulo de prueba/prueba. Hazlo asi:

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

export default UserStubComponent;

Ahora, en todas partes cuando importa el stub, tenemos que evitar corchetes como los siguientes:
import UserStubComponent from 'path'

Espero que funcione. Para mí, resuelve los problemas de compilación de AOT.

En mi caso, lo arreglé. El problema fue con la carcasa. Usé mayúsculas para las carpetas, pero la importación automática del código VS importó la ruta con minúsculas.

@ renilbabu03 JS distingue entre mayúsculas y minúsculas.

En mi caso, lo arreglé para mis pruebas unitarias, donde me burlé de la tubería de traducción.

Cambié el export class a 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;

¿Alguna solución para esto?
Probé export default <class> pero cuando ejecuto ng serve --aot , arroja un error: valor inesperado 'nulo' exportado por el módulo .

Es muy frustrante.

@redplane ¿Por qué quieres hacer eso? Me refiero a la exportación default .

Así es como lo hacen ellos mismos:
https://github.com/angular/angular/blob/master/aio/content/examples/testing/src/testing/router-link-directive-stub.ts

A menos que import un activo exported , ¿por qué a Angular le importa si el archivo existe?

La mayoría de las veces estoy refactorizando un componente o eliminando componentes y solo quiero comentar las referencias de componentes obsoletos como lo hice en los días de CommonJS. Esto sería lo suficientemente seguro ya que nunca uso archivos de barril porque me han quemado demasiadas veces en ese frente, y que Angular me obligue a comprometerme a eliminar físicamente los activos de mi proyecto es simplemente inaceptable cuando estoy hasta el cuello. una fase de prototipo...

Estoy atascado en Angular 6 porque soy el único desarrollador que trabaja en este proyecto y sería un infierno refactorizar las cosas para obtener las últimas herramientas estables en medio de tener que enviar nuevas funciones... al menos sería genial si Angular 6+ pudiera parchearse con un indicador del compilador para deshabilitar este comportamiento...

En mi caso, tengo una configuración de proyecto de biblioteca angular. En uno de mis componentes dentro de la biblioteca, he declarado algunas enumeraciones, para usar estas enumeraciones en mi proyecto de aplicación, estaba importando con una ruta relativa al directorio de proyectos en la raíz de mi aplicación.

Esta es la razón por la cual el compilador angular quería que mi componente de biblioteca se declarara en cualquiera de los ngModules del proyecto de aplicación.

Para resolver este error, debo declarar mis enumeraciones en el archivo public-api.ts y usarlas en el proyecto de la aplicación con una importación directa desde la biblioteca y no con una ruta de importación relativa.

Por ejemplo:
Nombre del proyecto de biblioteca: components-lib
Nombre del proyecto de aplicación: aplicación de demostración

Para usar cualquier interfaz, clase, enumeración , etc. declarada dentro del proyecto de la biblioteca, impórtelos con una ruta directa:

importar { SearchEnum } desde 'components-lib';

y no lo hagas
import { SearchEnum } from '../../../projects/components-lib/path-to-your-component';

Espero que esto ayude a alguien en el futuro, ya que he pasado horas encontrándolo yo mismo.

Tener un problema para mantener la compatibilidad de una biblioteca creada con ng 9 que quería que las personas que ejecutan ng 8 pudieran usar.

Ofrezco a través de la biblioteca algunas clases de utilidad que sus componentes pueden ampliar. En esa cadena de clases principales, algunas de ellas son abstractas y con ng 9 deben tener @Directive({ selector: 'random' }) para ser compatibles con ng 8.

Así que casi me salgo con la mía... PERO:

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.`

No expongo ningún módulo dentro de la biblioteca, se supone que las personas solo deben ampliar las clases que ofrecemos. Pero no quiero que tengan que importar las clases principales en sus módulos (no tendría ningún sentido).

Así que estoy atascado y simplemente eliminaré una versión de cambio de última hora que requiere que las personas actualicen a ng 9 en lugar de tener compatibilidad con versiones anteriores.

Hola a todos, perdón por el silencio sobre este tema.

ngc en View Engine, por diseño, genera archivos ngfactory para cada componente en la "compilación", es decir, el conjunto completo de archivos TS definidos por su tsconfig. Así es como TypeScript
funciona en sí mismo: compila todos los archivos definidos por un tsconfig. ngc solo está haciendo un procesamiento adicional además de eso.

Entonces, si un @Component está presente en esa compilación y ngc puede verlo (lo que significa que es de nivel superior y exportado), ngc intentará compilarlo. No hay otra forma de evitar esto que no sea asegurarse de que ngc no compile el archivo que declara el componente en primer lugar.

La forma correcta de hacerlo es hacer un alcance de su tsconfig. Por ejemplo, puede tener un tsconfig de nivel superior para su editor, que incluye todos los archivos, y luego un tsconfig.app.json para la compilación de su aplicación específicamente, que hereda de la configuración del editor y excluye los archivos de especificaciones. Solo la configuración de la aplicación se compilaría con ngc.

Los proyectos (cada tsconfig es un "proyecto") deben estructurarse de manera que un componente y su módulo siempre se compilen juntos.

En Ivy todavía se aplican en gran medida las mismas reglas, con varias pequeñas diferencias:

• Por defecto, Ivy intentará compilar _any_ @Component , independientemente de si se exporta.
• Ya no es un error, en Ivy, tener un componente sin módulo. Sin embargo, aún obtendrá errores de verificación de tipo de plantilla si ese componente intenta usar otros componentes/directivas en su plantilla, ya que sin un módulo nada más será visible para ese componente.
• Es posible decirle al compilador Ivy que ignore un componente o módulo en particular y lo deje hasta el tiempo de ejecución, agregando un indicador jit: true al decorador.

@alxhub ¡Me alegra saber que ya no es un error!

Entiendo que ngc intentará compilar todo lo que haría tsc, y que tsc compilará todo lo que esté dentro de su alcance. Dicho esto, el requisito de que se agregue un componente a un módulo es 100% una preocupación angular, por lo que eliminarlo del alcance de su proyecto mecanografiado se siente como patear la lata en el futuro. Además, dado que los patrones como los archivos de barril son comunes, puede ser difícil eliminar realmente un solo archivo de la compilación, sin eliminarlo TAMBIÉN de cualquier reexportación en el camino. Esta es la razón por la cual las llamadas para simplemente "excluir esos componentes" a menudo fueron recibidas con insatisfacción.

Con respecto a la limitación restante con ivy (los errores de plantilla en componentes sin módulos), ¿es demasiado pedir que también sean advertencias? Entiendo que puede ser más difícil (o imposible) si la verificación de tipo ocurre antes de que el componente se identifique como sin módulo, pero me parece que una advertencia del tipo Warning: ExampleUnusedComponent does not belong to an NgModule, and will be excluded from the output captura con precisión la idea de que el El componente (y cualquier otro al que haga referencia) no se incluirá a menos que se agregue a un ngModule.

En general, estoy muy emocionado de ver el movimiento en este tema y espero probar mi caso de uso original con los nuevos cambios en el compilador ivy.