Angular-cli: Advertencias al usar una interfaz exportada en una clase

Tengo el mismo problema cuando sigo el ejemplo de token de inyección de dependencia que se proporciona en los documentos angulares: https://angular.io/docs/ts/latest/guide/dependency-injection.html#dependency -injection-tokens

No he comprobado si quizás los documentos se han actualizado, pero se han implementado en mi aplicación en función de la documentación de hace unos 2 meses. Recibo la siguiente advertencia:
export 'AppConfig' was not found in '../app.config'
Siempre que importe la interfaz.

Funciona bien a pesar de la advertencia, así que solo he estado esperando que desaparezca eventualmente a medida que las cosas maduren

@TheLarkInn, ¿puedes pesar?

Viendo el mismo error también.

Este es un error que identificamos, pero necesito encontrarlo en nuestro repositorio de paquete web para vincularlo a este.

teniendo el mismo problema. (Funciona bien a pesar de la advertencia)
¿está exportando más de una interfaz / clase / const desde el archivo?
El problema se detuvo después de exportar cada interfaz desde su propio archivo dedicado.

lo que significa que si tuviera un archivo con varias exportaciones, recibí advertencias en la compilación (la exportación 'MyInterface1' no se encontró en '../file')

file.ts

export interface MyInterface1 {}
export interface MyInterface2 {}

después de la refactorización - sin advertencia

file1.ts

export interface MyInterface1 {}

file2.ts

export interface MyInterface2 {}

Por lo general (y viniendo del mundo Java), de todos modos, consideraría que es un buen estilo dividir tales definiciones múltiples en archivos separados.
Pero dado que Angular recomienda inyectar interfaces (con un OpaqueToken), parece obvio definir la interfaz y su token relacionado en el mismo archivo, lo que desencadena este error.

Este problema se solucionó para mí después de actualizar a angular-cli 1.0.0-beta.17 y angular 2.1.0

@teledemic interesante, todavía tengo el mismo problema en esas versiones.

¡Eh! Recientemente actualicé todos mis paquetes. No estoy seguro de qué podría haber sido aparte de esos dos. FWIW:

  "dependencies": {
    "@angular/common": "2.1.0",
    "@angular/compiler": "2.1.0",
    "@angular/core": "2.1.0",
    "@angular/forms": "2.1.0",
    "@angular/http": "2.1.0",
    "@angular/platform-browser": "2.1.0",
    "@angular/platform-browser-dynamic": "2.1.0",
    "@angular/router": "3.1.0",
    "angular2-highcharts": "^0.3.4",
    "bootstrap": "4.0.0-alpha.4",
    "core-js": "^2.4.1",
    "jwt-decode": "2.1.0",
    "ng2-bootstrap": "^1.1.14",
    "rxjs": "5.0.0-rc.1",
    "ts-helpers": "^1.1.1",
    "zone.js": "^0.6.25"
  },
  "devDependencies": {
    "@types/jasmine": "^2.5.35",
    "@types/jwt-decode": "1.4.28",
    "angular-cli": "^1.0.0-beta.17",
    "codelyzer": "~1.0.0-beta.1",
    "jasmine-core": "2.5.2",
    "jasmine-spec-reporter": "2.7.0",
    "karma": "1.3.0",
    "karma-chrome-launcher": "^2.0.0",
    "karma-cli": "^1.0.1",
    "karma-jasmine": "^1.0.2",
    "karma-remap-istanbul": "^0.2.1",
    "protractor": "4.0.9",
    "ts-node": "1.4.3",
    "tslint": "3.15.1",
    "typescript": "^2.0.3"
  }

Estoy en Angular 2.1.0 y CLI beta 17. Tengo una estructura que se ve así:

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

export const APP_CONFIG = new OpaqueToken('app.config');

export interface AppConfig {
  geoserverUrl: string;
  ...
}

que desencadena una advertencia:
export 'AppConfig' was not found in '../../app.config'
cada vez que intento inyectar el token nombrado, por ejemplo

constructor(private http: Http, @Inject(APP_CONFIG) private appConfig: AppConfig) {
  ...
}

Si hago de AppConfig una clase, funciona sin advertencias. (Aunque, por supuesto, debe crearse una instancia diferente).
Me pregunto si algo en la secuencia de compilación simplemente descarta las interfaces (demasiado pronto), ya que en realidad no existen en el JavaScript final.

El mismo problema con el decorador de propiedades @Input . Solución alternativa encontrada:

@Input() myProp = <MyInterface1>null

en vez de

@Input() myProp: MyInterface1

ahora no hay advertencias

¿Alguien puede actualizar el estado de esto? Estoy en v1.0.0-beta.21 y sigo recibiendo las advertencias.

Recibo un error en CLI: No se puede encontrar el nombre 'HERO_DI_CONFIG'. (siguió el ejemplo completo sobre documentación angular). A pesar del error, todo funciona bien, una consola Chrome no registra ningún error.

Solo para agregar el conocimiento que puedo, si está utilizando el ejemplo de APP_CONFIG y obtiene la advertencia de armonía, moví la declaración de interfaz (y solo la declaración de interfaz) a otro archivo (iapp.config.ts),

export interface IAppConfig {
  API_URL: string;
}

importó IAppConfig en app.config.ts (ya que ahora está en otro archivo), e hizo las importaciones en los componentes por separado, por ejemplo:

import { APP_CONFIG } from '../app.config';
import { IAppConfig } from '../iapp-config';

Todo lo demás permaneció igual (no tuve que convertirlo en una clase, etc.). Los archivos / importaciones adicionales son voluminosos, pero no hay advertencias y funcionan como se esperaba.

Recientemente intenté crear un proveedor de servicios (sí, también siguiendo la guía DI en https://angular.io/docs/ts/latest/guide/dependency-injection.html#!#injector-providers) y copié el código en el archivo hero.service.provider.ts. Parece que exige que el archivo exporte CamelCase en lugar de camelCase.

Probé el repositorio de

Después de ng init , sobrescribiendo la mayoría de los archivos excepto app.component. *. Ts.
ng build todavía da la advertencia:

Hash: cad6eef25bd1670f6646
Time: 10163ms
chunk    {0} main.bundle.js, main.bundle.map (main) 5.23 kB {2} [initial] [rendered]
chunk    {1} styles.bundle.css, styles.bundle.map, styles.bundle.map (styles) 1.77 kB {3} [initial] [rendered]
chunk    {2} vendor.bundle.js, vendor.bundle.map (vendor) 2.61 MB [initial] [rendered]
chunk    {3} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry] [rendered]

WARNING in ./src/app/app.component.ts
18:55-68 "export 'TestInterface' was not found in './test.service'

WARNING in ./src/app/app.component.ts
18:88-101 "export 'TestInterface' was not found in './test.service'

ng version es

                         _                           _  _

__ _ _ __ __ _ _ _ | | __ _ _ __ ___ | | (_)
/ _ || '_ \ / _ || | | || | / _` || '__ | _____ / __ || || |
| (_ | || | | || (_ | || | _ | || || (_ | || | | _____ || (__ | || |
__, _ || _ | | _ | __, | __, _ || _ | __, _ || _ | ___ || _ || _ |
| ___ /
angular-cli: 1.0.0-beta.26
nodo: 7.4.0
sistema operativo: darwin x64
@ angular / común: 2.4.4
@ angular / compilador: 2.4.4
@ angular / núcleo: 2.4.4
@ angular / formas: 2.4.4
@ angular / http: 2.4.4
@ angular / plataforma-navegador: 2.4.4
@ angular / plataforma-navegador-dinámico: 2.4.4
@ angular / enrutador: 3.4.4
@ angular / compilador-cli: 2.4.4

Todavía tengo esta advertencia, como informó @catull .

La solución actual que sugirió @Iverson funciona para mí.
Pero al principio no entendí lo que significaba.
Es una conversión de tipo mecanografiado, dice "en myProp hay un null (inicialmente), pero SERÁ del tipo MyInterface1

También se puede escribir como:
@Input() myProp = null as MyInterface1;

Realmente me gustaría ver esto resuelto

Sigo experimentando exactamente el problema descrito por @wulfsberg.

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

export let SKYPE_CONFIG_TOKEN = new OpaqueToken('skype.config');

export interface SkypeConfig {
    ...
}

Todo funciona, pero recibo esta advertencia:

105:93-104 "export 'SkypeConfig' was not found in './skype.config'

Como parece ser un código legal (y recomendado), sería mejor si no arrojara una advertencia.

Hay una solución mejor y más simple: mueva todas las interfaces en un `myfunctionality.interfaces.ts 'relevante con exportaciones normales

export interface MyFunctionality {
   foo: string;
}

y funciona como un encanto, sin advertencias. Y separa tus interfaces en sus propios archivos, lo cual es bueno.

Este problema es muy molesto.
¿Podrías arreglarlo?

También esperando que este problema se solucione desde hace mucho tiempo ...

Si extiende una interfaz, la advertencia permanece cuando divide las interfaces en archivos

Esto está recibiendo más atención de los usuarios de la que debería y menos atención de los mantenedores a medida que veo las fechas. De todos modos, no vengo aquí para quejarme (ya que sé que el problema es difícil), sino para proporcionar una solución válida.

Nuestro equipo utiliza muchas interfaces. Pero también muchos barriles (esos archivos de índice donde simplemente reexporta material público). Una solución que nos está funcionando perfectamente es utilizar reexportaciones explícitas, es decir:

En lugar de usar export * from './file-with-interfaces'; en ese index.ts , hacemos export { SomeClass, SomeType, AnInterface1, AnInterface2 } from './file-with-interfaces';

Más tarde, el uso de import { SomeClass, AnInterface1, OtherClass } from './the-folder-with-barrel'; funciona en la aplicación y no muestra advertencias. Espero que esto pueda ayudar a algunas almas afligidas;).

PD: tenemos 62 interfaces y 0 advertencias con este método;)

Hice la misma sugerencia que @ShadowManu justo arriba y obtuve 3 votos negativos; sería bueno si explicaras tus razones: +1:

@anodynos Fragmentar su código en el doble de la cantidad de archivos para usar un OpaqueToken angular-ideomático no es óptimo. Como mencioné, vengo del mundo Java y estoy bastante acostumbrado al estilo de "un archivo, una interfaz", pero en este caso realmente se siente como algo incorrecto. (Y desde la perspectiva del idioma, debería funcionar).

Reglas de Vanilla ES6 / ES7 !!!

* patos *

@anodynos, sin embargo, hay un par de diferencias. 1) no está obligado a dejar de lado las interfaces. Solo colócalos donde lo consideres necesario. 2) El barril con reexportaciones explícitas es de alguna manera (sí, no entiendo la razón en particular) el que hace desaparecer las advertencias.

@anodynos @ShadowManu
Las soluciones que sugieres no resuelven el problema, son solo soluciones:

• @anodynos Quiero mantener el OpaqueToken y la interfaz en el mismo archivo;
• @ShadowManu No obliguen a usar barriles.
  Como dijo @wulfsberg , debería funcionar desde la perspectiva del lenguaje y creo que esta es la razón principal por la que está recibiendo el pulgar hacia abajo. Personalmente, prefiero recibir los mensajes de advertencia que adoptar cualquiera de esas dos soluciones.

Gracias @JulienBroi - algunos comentarios:

• No necesita OpaqueToken & IOpaqueToken o lo que sea en el mismo archivo; puede tener un opaque-token-interfaces.ts o opaque-token-types.ts y pegar toda la interfaz y escribir cosas relacionadas ahí.

• ¿Qué pasa con los barriles?

No lo necesito , pero lo quiero, el idioma lo permite y Angular lo recomienda. Insistir en que tengo que hacerlo de otra manera debido a un error no es una buena solución.

Es una solución alternativa y no debería ser necesaria. Pero para aquellos desesperados, hay algo que se puede hacer mientras tanto. Revertir es más tarde tan simple como eliminar los archivos y seguir las importaciones rotas.

¿Podría un mantenedor bloquear este problema? Recibo spam en mi bandeja de entrada y ninguno de estos comentarios es útil.

@MazeChaZer Todo lo que necesita hacer es hacer clic en el botón "Cancelar

@catull Me gustaría recibir una notificación cuando se resuelva este problema

Para el registro, el problema correspondiente en webpack es webpack / webpack # 2977.

Como explica @hccampos allí, toca clases con decoradores (anotaciones):

las clases que contienen decoradores y utilizan una interfaz importada de otro archivo activan la advertencia. Si bien todo funciona normalmente, sería bueno deshacerse de las advertencias.

Personalmente, puedo decir que en realidad es solo para la clase de un miembro de la clase anotado con @Input que veo el problema, no se debe a la clase en sí:

@Input() component: IComponentRow;

disparará:

WARNING in ./src/app/features/cockpit/workspaces/petals-content/petals-component-view/petals-component-overview/petals-component-overview.component.ts
46:50-63 "export 'IComponentRow' was not found in '../../../state/components/component.interface'

El problema no se debe al paquete web, sino a algo relacionado con los decoradores / mecanografiado (como lo explica @sokra : https://github.com/webpack/webpack/issues/2977#issuecomment-245887841). Se hace referencia a la interfaz en el código javascript generado por mecanografiado y, por lo tanto, el paquete web no puede encontrarlo (ya que no tienen una existencia real en el ámbito javascript).

@filipesilva, así que creo que el problema proviene del propio mecanografiado.

Tengo una situación similar. Tengo varias interfaces en el mismo archivo, todas exportadas. De otros archivos, los importo y recibo una advertencia de que no puede encontrarlos. Si divido cada interfaz en su propio archivo, la advertencia desaparece.

A veces tengo interfaces y clases en el mismo archivo, el mismo resultado al importar las interfaces.

`` ADVERTENCIA en ./src/app/shared/services/ai.service.ts
368: 57-64 "no se encontró la exportación 'IConfig' en '../models/app-insights'

 ```// app-insights.ts
export interface IAppInsights {
  // ...
}

// some-other-file.ts import { IConfig } from '../models/app-insights'; // ...

Cosas que funcionaron:

1. dividir cada interfaz en su propio archivo
2. hazlos clases abstractas

VS Code está contento con esto. VS Code puede encontrar la importación, puede navegar hasta la definición. Entonces parece que está bien usar TypeScript ... pero el compilador no.

cc @alexeagle como un FYI

Esto parece ser una cosa de TypeScript. ?

cambiamos nuestro módulo tsconfig.js de es6 a commonjs y las advertencias desaparecieron, según el código generado, no estoy seguro de qué es diferente.

Ingrese el código del decorador con es6:
__Decorar([
__webpack_require __. i (__ WEBPACK_IMPORTED_MODULE_0__angular_core __ ["Entrada"]) (),
__metadata (' design: type ', (typeof (_a = typeof __WEBPACK_IMPORTED_MODULE_1__models_user_info __ ["UserInfo"]! == 'undefined' && __WEBPACK_IMPORTED_MODULE_1__models_user_info __ |
], HeaderComponent.prototype, "usuario", void 0);

Ingrese el código del decorador con commonjs:
__Decorar([
core_1.Input (),
__metadata (' design: type ', (typeof (_a = typeof user_info_1.UserInfo! == 'undefined' && user_info_1.UserInfo) === 'function' && _a) || Object)
], HeaderComponent.prototype, "usuario", void 0);

Necesitamos una mejor manera de aislar qué capa está causando el problema; parece que la magia CLI angular lo está dificultando. ¿Quizás una reproducción mínima sin CLI ayudaría?

@alexeagle No tengo una reproducción mínima, aunque intentaré encontrar una mejor.

Mientras tanto, si clona este repositorio y la rama, ejecute npm i , luego ejecute ng b verá los problemas que mencioné.

https://github.com/projectkudu/AzureFunctionsPortal/tree/upgrade-angular-v4

Lo siento, no tendré tiempo para investigar hoy. La advertencia viene del paquete web, ¿verdad? ¿Podría ser que TypeScript haya borrado la interfaz del archivo .js de salida, pero algún otro código todavía lo hace referencia? (intente pegar el contenido .ts en el patio de juegos de TypeScript para ver qué emite)

Sin preocupaciones, sin prisas. Es una advertencia, no un error.

El compilador de mecanografiado genera un archivo vacío. Pero hay otras interfaces en ese archivo que están bien.

Otra observación interesante es que si muevo cada interfaz a su propio archivo, la advertencia desaparece

También estoy experimentando lo mismo, pero sucede con los alias de tipo export type MyTypeAlias = .... también, no solo con las interfaces.

Solía ​​poder ignorar esta advertencia, pero ahora, después de actualizar a @ angular / cli 1.0.1, aparecerá un error en el navegador que dice "No se pudo compilar" junto con el error de que mi interfaz no se encuentra en la fuente. archivo. ¿Por qué una advertencia impide su ejecución?

En @ angular / cli: 1.0.1 no tengo advertencia, pero error:

¿Debo poner cada interfaz o escribir en un archivo separado? ¿Incluso muy pequeño? Por ejemplo:

export type SelectorDataMapperFn<T> = (term?: string) => Observable<T[]>;
export type SelectorListItemMapperFn<T> = (value: T) => SelectorSelectItem<T>;
export type SelectorCompareWithFn<T> = (value1: T, value2: T) => boolean;
export type SelectorCreateNewItemFn<T> = (value: string) => void;

¿En archivo separado cada uno? ¿Esta todo bien?

@manofearth Por el momento es la única posibilidad de sortear el error.

Sí, la actualización de 1.0.0 a 1.0.1 evita que la interfaz de usuario se cargue ahora. Sin embargo, los errores mostrados (como en la imagen de 1.0.0 embargo,

Encontré que el error desaparece si cambio las importaciones de import { X } from './x' a import * as ModuleX from './x' . Pero no es muy conveniente anteponer todos los usos de X en el código con el alias del módulo: ModuleX.X .

Hola,
'
// prueba.ts
prueba de interfaz de exportación {}

// app.ts
importar {prueba} de './test'
'
No recibo ninguna advertencia, pero la importación resulta indefinida.

mismo problema

Si coloca todas las interfaces en un solo tipo (por ejemplo, un archivo types.ts) y luego las importa desde allí, no debería obtener errores.

El problema ocurre cuando hay algún código no relacionado con el tipo en un archivo mezclado con algunos tipos e interfaces. En ese caso, webpack intenta importar un archivo y buscar un símbolo en él, pero no existe. Si las interfaces están todas en un archivo separado, TS solo las usa para la verificación de tipos y webpack no se preocupa por eso.

Hmm, lo separé; sí, no hay error, pero cuando importo el archivo,
no se pudo hacer referencia a la interfaz que exporté. Se declara como
indefinido produce errores en códigos posteriores; ¿Me estoy perdiendo de algo?
El jueves 27 de abril de 2017 a las 6:39 p.m. Hugo Campos [email protected]
escribió:

Si coloca todas las interfaces solas en un solo tipo (digamos un archivo types.ts)
y luego importarlos desde allí, no debería obtener errores.

El problema ocurre cuando hay algún código no relacionado con el tipo en un archivo
mezclado con algunos tipos e interfaces. En ese caso, el paquete web intenta importar
un archivo y busque un símbolo en él, pero no existe. Si las interfaces
están todos en un archivo separado, solo los usa TS para la verificación de tipos y
webpack no se preocupa por eso.

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

gracias, pero no podemos solucionarlo, sé que funciona con una solución alternativa pero no puedo mover todas mis interfaces en cada módulo a un archivo. necesita arreglar

@hccampos

@istiti para ser honesto, no veo que esto se solucione pronto. No es realmente un problema de CLI angular y no es realmente un problema de Webpack. Tampoco es un problema de TypeScript ... es algo intermedio, y creo que nadie puede solucionarlo fácilmente.

Tengo curiosidad por saber si la CLI está usando Rollup. Experimenté el mismo tipo de problema en un proyecto Ionic 2+ cuando usé Rollup en lugar de Webpack para agrupar. Entonces, si la CLI usa Rollup, creo que podría ser donde reside la fuente de este problema.

Solo para su información para todos aquí, las advertencias no bloquean la interfaz de usuario en 1.0.2 o 1.1.0-beta.0 , por lo que puede actualizar más allá de 1.0.1 si es necesario.

Hola a todos, tengo el mismo problema. Estaba siguiendo la guía de

Sin embargo, ahora que veo que esto aún no se ha resuelto, cambié de nuevo a clases.

Mi pregunta es, ¿por qué usar interfaces en lugar de clases? ¿Cuál es la verdadera diferencia?

¿Por qué? Una clase puede actuar como una interfaz (use implementos en lugar de extensiones).

La diferencia entre una clase y una interfaz es esta. La clase dice algo sobre cómo está construida la cosa. Qué tipo de código tiene detrás. Que puede contener métodos y así sucesivamente. La interfaz solo habla de la forma de los datos. Entonces, en términos de comunicar a otros desarrolladores, el significado del código y la interfaz es la forma más clara de hablar sobre los datos que su aplicación no construye y no sabe nada sobre la construcción. Por ejemplo, algunos datos que llegan a través del cable como JSON luego se deserializan; nunca será realmente una instancia de ninguna clase que no sea Object. Pero puede que coincida estructuralmente con una interfaz.

TypeScript tiene un interesante "truco" en torno a las clases. Si define la clase que solo tiene campos, puede tratarla como una interfaz. Incluso pretenderá que un objeto es una instancia de una clase de la que claramente no lo es, la clase solo tiene campos (y por lo tanto funciona como una interfaz). Creo que es una idea horrible, no creo que sea una buena característica y debería eliminarse. Pero nadie me preguntó :-)

La diferencia se vuelve marcada tan pronto como se agrega un método. Una vez que una clase o interfaz tiene un solo método, la capacidad de fingir que son iguales se evapora.

De acuerdo @kylecordes , esta declaración probablemente está haciendo un mal uso del contexto: "Estaba siguiendo la guía de estilo de angular usando clases en lugar de interfaces para las definiciones de tipos".

Una clase y una interfaz tienen dos propósitos muy diferentes. Uno se trata de implementación concreta, el otro comportamiento abstraído. Estoy seguro de que la guía de estilo angular no equipararía a los dos como intercambiables.

@Snesi , la diferencia es que una clase es algo concreto. Por ejemplo, "Car" no es un comportamiento, o (como Scala los llama, lo que para mí tiene mucho más sentido que "interfaz"), un "rasgo". El coche es el coche. Pero, "Coche" puede ser "Manejable". Ese es un rasgo que se puede compartir entre diferentes tipos de cosas; una bicicleta, una cortadora de césped, etc. Si dijeras, "Oh, acabo de crear ICar, IBike, IPowerMower" ... eso es un mal uso, que siempre lleva a tu pregunta, "¿por qué molestarse con las interfaces?" Es mejor hacer algo como "Vehículo" (subclase Coche, Bicicleta, PowerMower), con características IDriveable, IFuelable, etc. De esta manera, incluso puede tener un vehículo, digamos, que no se puede conducir, crearía "IRemotelyOperated" o algunos tales. ISelfDriveable extiende IDriveable. Entiendes la idea. Ahora puede tener un automóvil que se puede operar de varias formas, especificadas por diferentes interfaces.

Pero si solo crea una interfaz que no hace nada cada vez más que reflejar la implementación completa de una cosa concreta específica, encontrará que terminará con muchas más interfaces de las que debería, porque no hay abstracción de comportamiento, y la interfaz simplemente aparecerá superfluo.

@tcoz @kylecordes Gracias, entiendo la diferencia en lenguajes como Java o PHP, pero si Typescript permite usar una clase como si fuera una interfaz, ¿por qué no adoptar ese truco?

Además, tienes razón @tcoz. Malinterpreté la guía angular. Esto es lo que dice sobre las interfaces:

Nombra una interfaz usando mayúsculas camel.

Considere nombrar una interfaz sin un prefijo I.

Considere usar una clase en lugar de una interfaz.

¿Por qué? Las pautas de TypeScript desaconsejan el prefijo I.

¿Por qué? Una clase sola es menos código que una clase más interfaz.

¿Por qué? Una clase puede actuar como una interfaz (use implementos en lugar de extensiones).

¿Por qué? Una clase de interfaz puede ser un token de búsqueda de proveedor en la inyección de dependencia angular.

Solo dice considerar usar una clase en lugar de una interfaz porque se puede implementar en lugar de extender y porque puede ser un token de búsqueda de proveedor para la inyección de dependencia en Angular (no tengo idea de qué es eso)

Diría por la misma razón que sugieres: es un truco. No estoy seguro de que el idioma sea un factor determinante. Una interfaz es una interfaz.

Ahora, si TypeScript tiene razones técnicas subyacentes para no usar interfaces de la forma en que todo lo demás lo hace porque el lenguaje en sí no puede admitirlo correctamente, eso es un asunto diferente. Pero deben dejar claro que este es el caso. Y cada vez más, parece que las interfaces pueden ser problemáticas en TS.

También todo el asunto del "sin yo" es dudoso. La guía de estilo de C #, el primer ejemplo de interfaz, muestra:

interfaz IEquatable

(Tenga en cuenta también que el nombre implica un comportamiento, no una "cosa" concreta).

Así que me parece contradictorio que TS diga "no" pero C # claramente dice "sí", a menos que el punto sea poder diferenciar una interfaz C # de una TS ... lo cual, de nuevo, sería una práctica cuestionable en mi humilde opinión. O, nuevamente, a menos que la razón sea la tecnología subyacente en sí.

Además, supongamos que está iterando una colección y filtrando algunos tipos. ¿Son interfaces o tipos de clases? ¿Cómo se sabe con solo mirar el código? En una revisión (como un GitHub lado a lado), donde no hay herramientas flotantes, etc., eso podría ser muy molesto.

¿Por qué apartarse de un estándar tan útil? Yo mismo, esa es una cosa de TS (si de hecho es una recomendación formal) que podría descartar.

He leído la guía de estilo y creo que está mal redactada. Lo que creo que significa es en lugar de hacer esto:

interface IItemService {}
class ItemService implements IItemService {}
class OtherService {
  constructor(itemService: IItemService) {}
}

para hacer esto:

class ItemService {}
class OtherService {
  constructor(itemService: ItemService) {}
}

Esto se debe a que, en el último caso, la clase en sí puede inyectarse por referencia (esto es lo que significa el bit "token de búsqueda de proveedor": el constructor de la clase se usa para identificar lo que estamos tratando de inyectar aquí).
La guía de estilo simplemente desaconseja un patrón que es bastante común, por ejemplo, en Java con Spring, donde cada dependencia debe ser una interfaz y luego el marco DI determina qué implementación usar. Afirma que en TypeScript eso crea una sobrecarga innecesaria y, en el 99% de los casos, su interfaz solo tendría una implementación de todos modos, por lo que no es necesario optimizar esto prematuramente aprovechando el polimorfismo.

No creo que la guía de estilo diga "use clases en lugar de interfaces siempre"; creo que dice "use solo clases en lugar de clase más interfaz para clases inyectables".

Independientemente, creo que esto está bastante fuera de tema y solo está alargando un hilo largo, por lo que probablemente deberíamos dejar de discutir la guía de estilo.

@tcoz

También todo el asunto del "sin yo" es dudoso. La guía de estilo de C #, el primer ejemplo de interfaz, muestra:

interfaz IEquatable

(Tenga en cuenta también que el nombre implica un comportamiento, no una "cosa" concreta).

Si sigues esa lógica, no necesitas fingir que soy igual para saber que es un comportamiento. El sufijo capaz de Equat able implica claramente que se trata de una interfaz.

Entonces soy completamente redundante en este ejemplo.

Algunos ejemplos bastante sencillos en los que eso no funciona. Ejemplo: "IComponent", "IProvider". Eso tendría que ser "Compentable", "Providerable". Eso sería extraño. Esos por cierto son de nuevo de C #.

Realmente no puedo ver una razón válida para hacer que TS sea diferente de todo lo demás en la tierra de esa manera, particularmente su analógico más cercano, C #.

Lamento haber mencionado esto, pero continuar con esta discusión sobre el estilo del código está completamente fuera de tema xD.

Por ahora, para no ver la advertencia export 'TestInterface' was not found in './test.service' Preferí usar clases en lugar de Interfaces, porque no quiero dividir cada Interfaz en archivos separados.

Y gracias al "hack" de mecanografiado que te permite usar clases como si fueran interfaces, siempre que se solucione este error, podría cambiar las clases a interfaces y todo debería seguir funcionando sin problemas.

Solo para ocultar un poco más este extraño error ... tengo la misma advertencia para:

// Warning: "export 'BillState' was not found in '../../state/reducers/bills'
@Input() bill: BillModel;

Sin embargo, si cambio el tipo para que sea una matriz de BillModel el error desaparece ...: oveja:

// No warning :-)
@Input() bill: BillModel[];

@gionkunz Tengo el mismo comportamiento que tú, excepto que está bloqueando todo mi sitio. Está solo en ciertos archivos, cuando importo la interfaz y la asigno como un tipo, obtengo el error datatypes_1 is not defined . datatypes es la carpeta en la que se encuentra mi interfaz. No importa si importo la interfaz desde el archivo de índice en datatypes o directamente desde el archivo donde se exporta. Pero, si lanzo el objeto como una matriz, puedo construir el proyecto.

Estoy experimentando el mismo problema al hacer referencia a interfaces de módulos de terceros.

Hola a todos, he estado analizando este problema y quería darles una actualización.

Hay dos partes del problema:

• las interfaces no existen realmente después de la compilación de TS.
• Webpack intenta seguir las importaciones en los módulos ES.

Entonces, para las cosas que deben existir y ser importadas después de la compilación, como un tipo decorado (por ejemplo, @Input() test: TestInterface ), recibirá una advertencia de que el paquete web no puede encontrar la importación. Simplemente ya no existe después de la compilación (AOT no sufre este problema por cierto).

Se han propuesto un par de soluciones, como mantener los archivos que solo tienen interfaces o declarar la interfaz en la misma clase que la usa. Estos abordan el problema de diferentes maneras.

Cuando tiene un archivo compuesto solo por interfaces, está vacío después de la compilación. Entonces, Webpack cree que es un módulo CommonJS (en lugar de un módulo ES) y no intenta averiguar sus exportaciones, asumiendo que lo que estamos importando está allí en tiempo de ejecución. Consulte https://github.com/webpack/webpack/issues/2977#issuecomment -245898520 para obtener más detalles.

Declarar la interfaz en el mismo módulo donde la usa significa que no hay exportación a seguir, así que no hay advertencia.

Verifiqué con la gente de TypeScript ( @mhegazy , @DanielRosenwasser) y @alexeagle , y esta es una situación desafortunada para la que no hay una solución clara.

La recomendación es utilizar un valor que exista después de la compilación para las propiedades decoradas . Por ejemplo, una clase o variable en lugar de una interfaz.

Sé que esto es frustrante porque se le anima a hacer un uso completo de TypeScript, pero es una limitación actual.

Comunicaré esto a los documentos para asegurarme de que se brinde orientación.

Gracias a todos los que han estado siguiendo esto, proporcionando contexto, reproducciones y soluciones. Lo siento, no tengo una solución real que lo haga desaparecer.

+1

@filipesilva Entonces, ¿la mejor práctica es usar la clase en su lugar?

@wilsoncook sí.

Recibí esta advertencia por primera vez hoy, aparentemente porque tenía un archivo que exportaba una constante y una interfaz. Lo extraño es que ya había estado usando la interfaz en otros lugares (dentro de los proveedores y dentro de otros modelos) durante un tiempo sin problemas. La advertencia no apareció hasta que intenté usar la interfaz de un componente .

La solución alternativa fue sacar la constante exportada de ese archivo. Parece que mientras los archivos TS individuales solo contengan construcciones en tiempo de compilación (por ejemplo, tipos, interfaces) O construcciones en tiempo de ejecución (clases, consts), pero no mezcladas, la advertencia no se producirá.

En mi humilde opinión, esto parece un enfoque mucho mejor que decirle a la gente que cambie al uso de clases en todas partes, porque si bien TypeScript puede tratar las anotaciones de tipo de clase de la misma manera que las anotaciones de tipo de interfaz, la semántica de las clases en JavaScript es bastante diferente. Las clases en JavaScript> ES2015 significan que estás esperando ciertos métodos y estás esperando un cierto prototipo y un cierto constructor con posiblemente ciertos campos estáticos en él, y estás esperando poder "instanciarlo" y siempre ser verdadero si coincide. Abusar de las clases para obtener seguridad de tipos en objetos de datos JS simples no es el camino correcto a seguir, en mi humilde opinión.

@mischkl misma preocupación

Entonces, ¿la mejor práctica es usar la clase en su lugar?

@filipesilva ¿ Pero, según tengo entendido, agrega código fuente adicional sin usar al paquete resultante o me pierdo algo?

En mi humilde opinión, esto parece un enfoque mucho mejor que decirle a la gente que se cambie a clases en todas partes

@mischkl La cuestión es que no se pueden dividir completamente las interfaces y el código real en algunas situaciones.Aqui esta uno de ellos:

import {SomeComponent} from './some.component';

export interface SomeInterface {
  ref: ComponentRef<SomeComponent>;
}

En este caso, debe importar el componente real para describir una interfaz y el archivo resultante no estará vacío después de la compilación.

@ th0r el ejemplo que menciona no debería ser un problema. El problema solo surge cuando exporta una combinación de elementos de tiempo de compilación y tiempo de ejecución en un archivo, por ejemplo:

export class SomeClass {
  foo: string;
}

export interface SomeInterface {
  bar: string;
}

@mischkl Me refiero a que su solución (extraer todas las cosas en tiempo de compilación en un archivo separado) no funcionará para mi ejemplo: extraje SomeInterface pero depende del código de tiempo de ejecución ( SomeComponent ) y el archivo resultante no estará vacío después de la compilación.

@ th0r Supongo que no especifiqué lo que quise decir exactamente lo suficiente. Puede mezclar y combinar material en tiempo de compilación con material que no es de tiempo de compilación tanto como desee AFAIK, los únicos problemas surgen cuando exporta ambos desde un archivo.

Entonces, la solución es separar todas las exportaciones de interfaces y tipos en archivos adicionales, que luego pueden importarse en otro lugar y usarse libremente.

Entonces, la solución es separar todas las exportaciones de interfaces y tipos en archivos adicionales, que luego pueden importarse en otro lugar y usarse libremente.

Esto no funcionará para mi ejemplo debido a esto (cita de este comentario ):

Cuando tiene un archivo compuesto solo por interfaces, está vacío después de la compilación. Entonces, Webpack cree que es un módulo CommonJS (en lugar de un módulo ES) y no intenta averiguar sus exportaciones, asumiendo que lo que estamos importando está allí en tiempo de ejecución.

En mi ejemplo, este archivo con interfaces no estará vacío porque importó SomeComponent en él que es necesario para describir SomeInterface .

@ th0r, ¿por qué no lo pruebas? Creo que encontrará que el resultado está vacío, a pesar de sus expectativas. Tenga en cuenta que está utilizando la clase aquí solo como una anotación de tipo y, lo que es más importante, no la reexporta explícitamente. Desde el exterior todo lo que se exporta es la interfaz que consta de anotaciones de tipo y nada más.

@mischkl ¡Lo siento! Tienes razón, simplemente intenté extraerlos en archivos separados nuevamente y las advertencias han desaparecido. Parece que hice algo mal la primera vez 🤔

@filipesilva, ¿hay algún problema de mecanografiado al que pueda hacer referencia este problema para un seguimiento futuro si se soluciona?

@zakhenry no que yo sepa, no.

¿Hay alguna razón por la que estas advertencias no se ejecuten en el navegador cuando son solo advertencias y no errores? Mi equipo está migrando una aplicación con más de 150 componentes y, de repente, nos apareció este problema. Parece haber aparecido completamente aleatorio después de haber migrado aproximadamente 30 componentes .. EDITAR: La actualización primero ayuda .. tenía una versión específica ingresada en package.json facepalm

Hasta ahora he descubierto que cualquier tipo de unión en las propiedades decoradas afectadas eliminará la advertencia, por ejemplo

@Input() someProp:MyMagicalInterface

resultará en una advertencia mientras

@Input() someProp:MyMagicalInterface | undefined

trabajará. Y ponerse completamente funky

@Input() someProp:MyMagicalInterface | MyMagicalInterface

también funciona. ¯_ (ツ) _ / ¯

por lo que sea que valga la pena ... cuando cambia el módulo en el tsconfig a "commonjs", el error desaparece. Es posible que esto no funcione para la mayoría de las situaciones, en la mía sí lo hace porque estoy usando un módulo principal que se compila fuera del proyecto cli (con ngc) y luego se vincula a él.

// ./src/app/wx.d.ts
export declare function config(): void;

// ./src/app/app.component.ts
import * as wx from './wx.d';

// using
wx.config();

ng serve lanzar Module build failed: Error: Debug Failure. False expression: Output generation failed .

Cambiar el módulo tsconfig a "commonjs" solucionó las advertencias para mí. Anteriormente estaba configurado en "es2015"

¿Hay alguna manera de silenciar esa advertencia?

@remmeier vea el comentario de arriba : puede suprimir la advertencia simplemente haciendo que el tipo sea una unión en sí mismo. Se logra el mismo tipo de seguridad y la advertencia desaparece. De ninguna manera es una solución, pero al menos puedes seguir desarrollando

El problema aún existe, ¿por qué está cerrado?

@RenaldasK hay una explicación larga (en breve, es la limitación que actualmente no se puede resolver) https://github.com/angular/angular-cli/issues/2034#issuecomment -302666897

Intente reescribir las interfaces a las clases si es posible (esto funciona para mí).
O una de las soluciones propuestas anteriormente (no probé ninguna de ellas).

Aparte de las advertencias de la consola, ¿existe alguna razón real para evitar este problema?

Todas las soluciones anteriores parecen un truco, y poner una interfaz de una sola línea en su propio archivo parece una pérdida de tiempo ...

Tener el mismo problema con un escenario como este:

export class Something { ... }
export type SomethingKey = Pick<Something , 'keyPropertyName'>;

en un archivo. Sin embargo, cuando agrego otra interfaz, clase o tipo a ese archivo, la interfaz se resuelve perfectamente bien. Este parece ser solo el problema con el tipo Pick<..> . Funciona, compila, transpila, solo da una advertencia en la CLI ...

@filipesilva
Gracias por analizar el problema en detalle. La solución más fácil que he encontrado es declarar un tipo de alias local en el archivo de componente para el tipo importado cuando sea necesario en un @Input ().
Entonces, para su ejemplo, en lugar de:

import {TestInterface} from ...
...
@Input() test: TestInterface

hacer un

import {TestInterface} from ...
type TestInterfaceAliasHack = TestInterface;
...
@Input() test: TestInterfaceAliasHack

Esto es realmente molesto. ¿Existe una solución real y no simplemente soluciones temporales?

¡Este problema es muy molesto!

Por el momento, solo una bandera para silenciar las advertencias sería genial ya que todo funciona perfectamente bien independientemente de las advertencias.

Dijeron que trabajando en eso, tengo el mismo problema, solo tengo que esperar o trabajar con una solución si es posible.

Chicos, este problema se explicó aquí: https://github.com/angular/angular-cli/issues/2034#issuecomment -302666897

Este es un problema sobre cómo funciona Webpack. @filipesilva, ¿hay alguna posibilidad de que esto se solucione algún día? ¿Hay temas abiertos para abordar este problema?

Frustrante, pero solo use una clase en lugar de una interfaz y funcionará sin advertencias.

Estaba enfrentando el mismo problema en los tipos y @Input () por una interfaz.
Resuelto teniendo un archivo con solo interfaces (y definiciones de tipos) y moviendo constantes y clases a un archivo diferente. Un poco de dolor de cabeza, pero no tanto como para requerir archivos separados para cada interfaz o tipo o algo por el estilo.

Aún así, si lo que alguien dijo arriba es correcto y cli está contento con:

@Input () foo =nulo;

No veo por qué el código transcompilado debería ser muy diferente para:

@Input () foo: Bar;

En la medida en que ese paquete web implosionará. ¿Existe alguna diferencia semántica específica entre los dos (además de la asignación nula explícita)?

Noté que este error ocurre cuando trato de exportar un Enum y una Interfaz en el mismo archivo. Dado que dividí la declaración Enum de las declaraciones de Interfaces, está bien, incluso si defino muchas interfaces en el mismo archivo. No me gustó dividir mi interfaz y enumeraciones en diferentes archivos porque comparten el mismo "contexto de dominio" en este caso, pero es la única forma de eliminar esta advertencia.

En Angular 4.3.1,
Extrañamente obtengo errores similares al importar en un archivo .ts pero no en otro en la misma carpeta.
Nuevamente, la misma importación funciona bien en un archivo, pero el otro obtiene

WARNING in ./src/app/foo/bar.ts
19:50-54 "export 'Tags' was not found in '../tar/tag.model'

siendo tag.model.ts

export type Tag = string;
export type Tags = Tag[];
export class TagSet {
    constructor(public category:string, public tags:Tags[]){}
}
export type TagList = TagSet[];

@polyglotinc , creo que la razón por la que solo ve el problema en un archivo es por la forma en que se utilizan los tipos importados. En mi caso, un archivo que contiene algo como:

@Input () foo: Etiqueta; // Esto causará la advertencia
@Input () barra: Etiqueta []; // Esto no causará la advertencia

La razón por la que pienso es que después de la transpilación, todavía necesita saber qué representa "Etiqueta" en el primero, pero no en el segundo, que es solo un JS Array.

Logré esta configuración igual a nulo y lancé el tipo:

@Input () foo = <SomeType> nulo

Esto lo arreglará:
@Inject (MD_DIALOG_DATA) orden público indefinido

Podría ser mejor para la verificación de nulos. Hay más información sobre el problema del paquete web: https://github.com/webpack/webpack/issues/2977

También el uso de una clase en lugar de una interfaz podría solucionarlo

Además, puede usar @Input() property: PropertyType | null; para evitar esto. Sin embargo, no se vende en esta solución alternativa ni en ninguna otra solución alternativa. Son sólo tiritas colocadas sobre el problema subyacente.

Hola,
Recibo advertencias cuando exporto un tipo literal de cadena de un archivo y lo importo en otro.
Me las arreglé para deshacerme de las advertencias moviendo esos tipos literales de cadena a un archivo d.ts .
Espero eso ayude !

Hola a todos,

He estado trabajando en una nueva canalización de compilación para Angular 5 y superior que debería ocuparse de estas advertencias además de otros problemas relacionados con el tipo.

Mi advertencia en la consola:

Advertencia: ./src/app/scheduler/event-form/event-form.component.ts
111: 78-86 "no se encontró la exportación 'DayEvent' en 'app / Scheduler / month-view / month-view.component'

Arreglé la advertencia haciendo:
Evento @Input (): DayEvent | nulo;

en lugar de hacer:
@Input () evento: DayEvent;

Tuve el mismo problema, pero no pude usar la unión de tipos porque mi entrada fue un establecedor:

@Input() set something(s: SpecialInterface) { /** */ }

El cambio de es2015 , según lo establecido por el generador de aplicaciones @angular/cli a commonjs como se indicó anteriormente, lo resolvió para mí.

@Inject(APP_CONFIG) config: AppConfig | AppConfig

es una solución realmente extraña, pero simplemente funciona xD

Sí, puedo confirmar lo que los estados de @vpArth también funcionaron para mí.

Recibo esta advertencia para las interfaces importadas a través de una biblioteca de módulos de funciones, sin embargo, la extraña solución funciona para suprimir la advertencia.

import { AccountSummary } from '@mylib/core
export class OrderComponent implements OnInit { @Input() account: AccountSummary; ...

Tuve el mismo problema al exportar una interfaz:

export interface ResourceRef {
  [id: string]: {
    expires: string;
    resources: Array<Ref>
  };
}

y usándolo con @Input() resourceRef: ResourceRef;

Luego simplemente cambié la interfaz para que sea una clase, que johnpapa también sugirió aquí :

export abstract class ResourceRef {
  [id: string]: {
    expires: string;
    resources: Array<Ref>
  };
}

Y la advertencia se fue.
Ahora, ¿hay alguna desventaja en eso?

@rafaelbiten usando una clase, incluso abstracta, generará código adicional para esa clase cuando se compile. Una interfaz proporciona verificación de tipos para objetos simples sin generar código adicional.

¿Se ha resuelto esto? No veo los errores con las siguientes versiones e importación (aunque originalmente estaba usando abstract class

CLI angular - v1.6.0
Versión del espacio de trabajo de TypeScript: 2.4.2
Versión de TypeScript VSCode: 2.6.1

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

export interface ContentfulKeysConfig {
  space: string;
  accessToken: string;
  contentTypeIds: {
    post: string;
  };
}

export const CONTENTFUL_KEYS_CONFIG = new InjectionToken<ContentfulKeysConfig>('contentful-keys.config');

import { CONTENTFUL_KEYS_CONFIG, ContentfulKeysConfig } from './config/contentful-keys.config';
private keysConfig: ContentfulKeysConfig;
constructor(@Inject(CONTENTFUL_KEYS_CONFIG) config: ContentfulKeysConfig) {
    super();
    this.keysConfig = config;

¿Por qué está cerrado?

Sigo viendo el problema para Angular CLI v1.6.3. ¿Por qué está cerrado?

Este problema está sucediendo. Tengo un archivo ts de un gran tamaño con muchas interfaces definidas. Solo dos de esas interfaces provocan esta advertencia durante la compilación. Sin embargo, puedo importar las interfaces sin problemas e intellisense funciona para las interfaces afectadas. El seguimiento de la pila muestra que el paquete cli activa la advertencia. Supongo que está bien ignorar esto siempre que se construya correctamente.

Supongo que está bien ignorar esto siempre que se construya correctamente.

sí @ yangwen2

En caso de que alguien lo esté buscando, ¡este parece ser el problema del paquete web ascendente que mencionó @TheLarkInn !

https://github.com/webpack/webpack/issues/7378

En mi caso, reiniciar ng serve ayudó. Solo tenía un export en mi archivo ts

Acabo de reiniciar el servidor y las advertencias desaparecieron.

Esto ya no es un problema. En su lugar, usé la clase abstracta.

Esto ya no es un problema. En su lugar, usé la clase abstracta.

¿Hay algún impacto en los tipos si cambiamos la interfaz a la clase abstracta?

Tengo este problema hoy al actualizar los paquetes de angular a 8.0.4 / 0.800.4

https://github.com/angular/angular-cli/issues/2034#issuecomment -249813801 lo arregló para mí

Tener este problema después de actualizar a angular 8

Tener este problema después de actualizar a angular 8

Simplemente mueva la interfaz / tipos de la aplicación del archivo problemático a un archivo *.ts separado y no agregue el código real allí.

@ th0r ¿te refieres a la interfaz que está causando el problema para eliminarlos y ponerlos en su propio archivo separado?

@hijazikaram sí. En mis proyectos, en caso de tales errores, simplemente muevo todas las interfaces / tipos del archivo que desencadena un error a un archivo separado, por ejemplo, <filename>.types.ts y exporto todos. Además, este archivo no debe contener ningún código real, por ejemplo, clases, funciones, variables, etc.

Mismo problema. Mover la interfaz a un archivo separado no ayuda si se usa el barril.

Mismo problema. realmente no quiero mover interfaces a archivos separados. Además, hay un problema para los archivos ts del agregador que hacen una gran cantidad de export * from .

@jeffwhelpley Acabo de agregar | nulo que solucionó el problema para mí

¿Por qué angular / mecanografiado nos lo dificulta? 😞

igual que @ mpgo13. Empecé a tener el problema cuando actualicé a la versión 8.0.4 / 0.800.4 ,

Pero en mi caso # 2034 (comentario) no funcionó para mí.

El error no solo ocurre dentro de mis propias bibliotecas, sino también en una de las bibliotecas ngrx

@tbnovaes Tuve el mismo problema hace unos días. Después de configurar la versión fija de angular devDependencies en 8.0.0 / 0.800.0, desapareció.

Para aquellos de ustedes que obtuvieron este error después de actualizar a 8.0.4 / 0.800.4 , consulte https://github.com/angular/angular-cli/issues/14876. Parece que habrá una solución en la próxima versión.

Este problema se ha bloqueado automáticamente debido a la inactividad.
Por favor, presente un nuevo problema si encuentra un problema similar o relacionado.

Obtenga más información sobre nuestra política de bloqueo automático de conversaciones .

_{_Esta acción ha sido realizada automáticamente por un bot._}