Actualizar. El compilador Ivy no crea el archivo lib-name.metadata.json en project_root/dist/lib-name .
¿Podría ser este el problema?

+1 tengo el mismo problema

Después de la versión 9, vamos a cambiar los componentes internos del servicio de idioma para usar el compilador Ivy. Hasta entonces, el servicio de idiomas tendría que depender de metadata.json para recuperar información adicional sobre una directiva.

Sí, este es el problema. Para resolver por el momento, necesitará construir la versión prod de su biblioteca que tiene "enableIvy": false en tsconfig. Esto luego genera el archivo de metadatos necesario en la carpeta dist.

es decir, ng build lib-component --prod

Pero también debe asegurarse de Restart Angular Language service después de cada compilación en vs-code.

Toda esta información no se encuentra fácilmente entre el complemento vs-code y el propio angular. Solo un aviso para cualquier otra persona que experimente este mismo problema.

Mi suposición de que

• https://github.com/angular/vscode-ng-language-service/issues/340 y
• https://github.com/angular/vscode-ng-language-service/issues/457
  están todos relacionados.

@jiverson con respecto a su solución ng build lib-component --prod para mí produce un error An unhandled exception occurred: Configuration 'production' is not set in the workspace. y he visto evidencia en otros lugares de que el indicador --prod para bibliotecas ya no es relevante. Sin embargo, estoy usando @ angular / cli v8.3.25 ... así que aunque se ha hecho referencia a este problema como un posible duplicado para # 665, no estoy tan seguro de que lo sea. ¿Alguna idea? / cc @ayazhafiz

¿Alguna actualización sobre esto? Tenemos nuestras propias bibliotecas desarrolladas y publicadas en ivy incluso en prod.

¡Se está trabajando para trasladar el servicio de idiomas a un backend Ivy!

Puedo confirmar que si lo hace:

• construir biblioteca con ng build my-library --prod y
• ctrl + shift + py luego seleccione "Reiniciar servidor de Angular Language"

los errores del tipo "'xyz' no es un elemento conocido" desaparecerán del proyecto principal de la biblioteca.

Según entendí que esto se debe a --prod se (entre otras cosas) generan my-library.metadata.json archivo en dist carpeta que luego será utilizado por el servidor de lenguaje para decir reconocen selectores de componentes definida en mi-biblioteca.

Ahora, uno esperaría que si npm publish biblioteca construida con ng build my-library --prod y luego npm install esa biblioteca en alguna otra aplicación Angular, el servidor de idioma vería el archivo de metadatos en ese npm (en la carpeta node_modules ) y no informaría que "'xyz' no es un elemento conocido".

Sin embargo, esto no está funcionando como se esperaba y que puede ver el mismo error en un proyecto que tiene npm install ed mi-biblioteca, a pesar de que hay un archivo de metadatos JSON presente en mi carpeta de biblioteca en node_modules.

¿Sería este el mismo error que en este número o un error diferente?

¿O hay alguna otra combinación mágica (o adicional) de teclas para presionar o comandos para entregar al servidor de idiomas para que procese las bibliotecas angulares npm install ed correctamente?

Parece que la nueva forma en que está trabajando Ivy es confiar en los metadatos de los archivos .d.ts y no más en los archivos metadat.json. La única razón por la que una compilación --prod está funcionando es porque su tsconfig está configurando enableIvy en false (como recomienda angular para las bibliotecas publicadas de npm). Este es un problema de servicio de idioma y no un problema de cli angular, ya que la compilación funcionará bien con o sin Ivy para una aplicación que use la biblioteca publicada.

El problema es doble:

1. Ivy elimina los archivos metadata.json, requeridos por ALS y otras herramientas también
2. Actualmente, ALS no es lo suficientemente inteligente como para obtener la información de los metadatos de Ivy en lugar de .metadata.json

¿Por qué es este un problema tan molesto?

• Ivy es el camino a seguir, y los desarrolladores de bibliotecas también lo harán,
• al crear una biblioteca en su proyecto de aplicación basado en Ivy, aún desea utilizar Ivy de un extremo a otro en su aplicación sin dejar de ser un buen ciudadano y publicar su biblioteca reutilizable en npm para que otros la usen.
• la mayoría de los desarrolladores usan el enlace npm o apuntan el tsconfig al directorio dist de la biblioteca para las importaciones durante el desarrollo de la aplicación, esa es la forma obvia de todos modos,
• es muy molesto tener vscode marcando cosas en su biblioteca como desconocidas,

Esto es lo que terminé haciendo para solucionar este problema, que puede ser aceptable para algunas personas en las mismas circunstancias. No ayudará a las personas que quieran utilizar sus bibliotecas publicables en las mismas condiciones que un usuario de dichas bibliotecas (es decir, del paquete npm publicado):

Suponiendo que está utilizando un monorepo o una estructura similar donde el código fuente de la biblioteca publicable es accesible de manera consistente para la aplicación que lo usa.

Supongamos que el paquete se llama 'happy-library' ...

1. Compile (con --prod) y publique el paquete de la biblioteca en npm como de costumbre. Debe utilizar --prod y ha desactivado la hiedra en la configuración de generación,
2. Actualice su tsconfig.json en la raíz del espacio de trabajo (o vscode no lo resolverá ...) para agregar un mapeo de ruta a ese paquete, apuntando al directorio de origen del paquete.
3. Importe el paquete en el código de la aplicación como si fuera de node_modules, es decir, import {whatever} from 'happy-library';

    "paths": {
      "happy-library": ["libs/happy-library/src/index.ts"]
    }

No es perfecto, pero al menos puedo usar mi propia biblioteca en una aplicación Ivy de extremo a extremo, también hecha por mí, sin los errores en vscode, mientras sigo compartiendo el amor y publicándolo en NPM para otros usuarios, y yo no es necesario que constantemente hilo / npm enlace y depure por qué ALS no está funcionando.

Interesado en comentarios si me he perdido algo ...

PD: repositorio completamente funcional con este método en https://github.com/abdes/happy-coding

¿Se ha avanzado en esto?

Parece que estará disponible para las pruebas beta en Angular 11 programadas para noviembre.

Consulte https://github.com/angular/vscode-ng-language-service/issues/335#issuecomment -693545000

Estoy ejecutando Angular 11 en mi proyecto (biblioteca construida también con Angular 11, con la marca --prod), y tengo el problema descrito por @nprasovict . Publiqué mi biblioteca en paquetes de Gitlab, y cuando la instalo en nuestro proyecto con npm install , Angular Language Service no reconoce mis componentes exportados provenientes de mi biblioteca. Parece que ha sido un problema durante mucho tiempo, ¿cuándo podemos esperar que se resuelva?

Creo que terminaré eliminando la extensión VSCode por ahora, pero perderé un desarrollo poderoso solo por esto ...

@schankam : https://github.com/angular/vscode-ng-language-service/issues/457#issuecomment -725569238

@JonWallsten Gracias, por lo que se publicará pronto si lo entiendo bien

Esto ha sido solucionado por el nuevo servicio de idioma nativo de Ivy, lanzado en v11.1.0 .

¡Buen trabajo, @kyliau!
Veo muchos errores nuevos en la plantilla cuando se trata de una verificación nula estricta y que nos hemos perdido, ¡realmente agradable!

@kyliau Hmmmm ... eso es raro. Estaba teniendo el mismo problema con una directiva declarada en una biblioteca y lo resolví siguiendo la sugerencia de construir la biblioteca con el interruptor --prod. El caso es que ya estoy en ALS 11.1.1 , por lo que, en teoría, esto ya no debería ser un problema, ¿verdad?
El proyecto es un multiproyecto CLI regular, con algunas bibliotecas y una aplicación.
No estoy seguro de la vinculación de npm ... No hice nada especial. La ruta de la biblioteca aparece en la raíz tsconfig.json.

Tengo el mismo problema. Construyo mi biblioteca con la bandera --prod , por lo que Ivy está deshabilitada.
Vinculé la carpeta dist de la biblioteca, vinculé el paquete a mi aplicación e importé el libmodule. Pero sigue recibiendo este error, que no es un elemento angular conocido.
El componente de la biblioteca está en la matriz declarations y en la matriz exports .

El componente se muestra, pero sigue apareciendo este error en vscode. versiones probadas:

11.1.3
11.2.1
0,1100,4

Estoy de acuerdo, esto probablemente no debería cerrarse @kyliau ... Tengo un ejemplo mínimo reproducible que hice para otro problema que podría servir para demostrar este también. Eche un vistazo a esto: https://github.com/vicatcu/monorepo-example-error (publicado originalmente en conexión con esta publicación SO )

Iré un paso más allá, si agrego la opción "enableIvy": false debajo de angularCompilerOptions en tsconfig.lib.json propósito de este comentario , como he hecho en esta rama de mi repositorio de ejemplo , mis errores desaparecen en vscode (dado que mi proyecto de ejemplo todavía está roto de alguna manera que no entiendo)

Solo para aclarar, estar en v11.1.x no es suficiente, debe habilitar el modo Ivy siguiendo las instrucciones aquí .
No debería tener que cambiar su tsconfig.*.json .
El hecho de que apareciera ... is not a known angular element significa que no estás en modo Ivy.
Para determinar en qué modo se encuentra, vaya al panel Output y busque el servicio de idioma angular. Debería mencionar a Ivy. (ver captura de pantalla a continuación).
Su proyecto no tiene que usar Ivy para usar el servicio de idioma Ivy, pero debe usar Angular> = v9.

Si después de verificar todo lo anterior y la extensión aún no funciona como se esperaba, abra un nuevo problema para ayudarnos a clasificar y reducir el ruido. ¡Muchos gracias!

@kyliau gracias Yo, por mi parte, ciertamente me lo había perdido.