Mise à jour. Le compilateur Ivy ne crée pas de fichier lib-name.metadata.json dans project_root/dist/lib-name .
Est-ce que ceci pourrait être le problème?

+1 J'ai le même problème

Après la version 9, nous allons basculer les internes du service de langage pour utiliser le compilateur Ivy. Jusque-là, le service de langue devrait s'appuyer sur metadata.json pour récupérer des informations supplémentaires sur une directive.

Oui, c'est le problème. Pour résoudre pour le moment, vous devrez créer la version prod de votre bibliothèque qui a "enableIvy": false dans tsconfig. Cela génère ensuite le fichier de métadonnées nécessaire dans le dossier dist.

ie ng build lib-component --prod

Mais vous devez également vous assurer de Restart Angular Language service après chaque build dans vs-code.

Toutes ces informations ne se trouvent pas facilement entre le plugin vs-code et angular lui-même. Juste un avertissement pour quiconque rencontre ce même problème.

Mon hypothèse que

• https://github.com/angular/vscode-ng-language-service/issues/340 et
• https://github.com/angular/vscode-ng-language-service/issues/457
  sont tous liés.

@jiverson concernant votre solution ng build lib-component --prod contournement An unhandled exception occurred: Configuration 'production' is not set in the workspace. et j'ai vu ailleurs des preuves que l'indicateur --prod pour les bibliothèques n'est plus pertinent. J'utilise cependant @ angular / cli v8.3.25 ... donc bien que ce problème ait été qualifié de duplicata possible pour # 665, je ne suis pas sûr que ce soit le cas. Des pensées? / cc @ayazhafiz

Des mises à jour à ce sujet? Nous avons nos propres bibliothèques développées et publiées dans le lierre même en prod.

Des travaux sont en cours pour déplacer le service linguistique vers un backend Ivy!

Je peux confirmer que si vous faites:

• construire une bibliothèque avec ng build my-library --prod et
• ctrl + shift + p puis sélectionnez "Redémarrer le serveur Angular Language"

la ou les erreurs de type "'xyz' n'est pas un élément connu" seront supprimées du projet parent de la bibliothèque.

Si j'ai bien compris, c'est parce que --prod générera (entre autres) un fichier my-library.metadata.json dans le dossier dist qui sera ensuite utilisé par le serveur de langue pour reconnaître les sélecteurs de composants définis dans ma bibliothèque.

Maintenant, on pourrait s'attendre à ce que si je npm publish bibliothèque construite avec ng build my-library --prod puis npm install cette bibliothèque dans une autre application Angular, le serveur de langue verrait le fichier de métadonnées dans celui installé npm (dans le dossier node_modules ) et ne rapporterait pas "'xyz' n'est pas un élément connu".

Toutefois, cela est ne fonctionne pas comme prévu et je peux voir la même erreur dans un projet qui a npm install ed ma bibliothèque, même si il y a un fichier JSON de métadonnées présentes dans le dossier my-bibliothèque node_modules.

Est-ce que ce serait le même bug que dans ce numéro ou un autre bug?

Ou y a-t-il une autre combinaison magique (ou supplémentaire) de touches à appuyer ou de commandes à donner au serveur de langage pour qu'il traite correctement les bibliothèques angulaires npm install ed?

Il semble que la nouvelle façon dont Ivy fonctionne consiste à s'appuyer sur les métadonnées des fichiers .d.ts et non plus sur les fichiers metadat.json. La seule raison pour laquelle une compilation --prod fonctionne est que votre tsconfig définit enableIvy sur false (comme recommandé par angular pour les bibliothèques publiées npm). Il s'agit d'un problème de service de langue et non d'un problème de cli angulaire, car la compilation fonctionnera très bien avec ou sans Ivy pour une application utilisant la bibliothèque publiée.

Le problème est double:

1. Ivy supprime les fichiers metadata.json, requis par ALS et d'autres outils également
2. ALS n'est actuellement pas assez intelligent pour obtenir les informations des métadonnées Ivy au lieu de .metadata.json

Pourquoi est-ce un problème très ennuyeux?

• Ivy est la voie à suivre, et les développeurs de bibliothèques en feront également la voie à suivre,
• lors de la création d'une bibliothèque dans votre projet d'application Ivy, vous voulez toujours utiliser Ivy de bout en bout dans votre application tout en étant un bon citoyen et en publiant votre bibliothèque réutilisable sur npm pour que d'autres puissent l'utiliser.
• la plupart des développeurs utilisent le lien npm ou pointent le tsconfig vers le répertoire dist de la bibliothèque pour les importations pendant le développement de l'application, c'est de toute façon la manière la plus évidente,
• c'est ennuyeux d'avoir vscode signalant des choses dans votre bibliothèque comme inconnues,

Voici ce que j'ai fini par faire pour contourner ce problème, qui peut être acceptable pour certaines personnes dans les mêmes circonstances. Cela n'aidera pas les personnes qui souhaitent utiliser leurs bibliothèques publiables dans les mêmes conditions qu'un utilisateur de ces bibliothèques (c'est-à-dire à partir du package npm publié):

En supposant que vous utilisez un monorepo ou une structure similaire où le code source de la bibliothèque publiable est accessible de manière cohérente à l'application qui l'utilise.

Supposons que le paquet s'appelle 'happy-library' ...

1. Construisez (avec --prod) et publiez le package de la bibliothèque sur npm comme d'habitude. Vous devez utiliser --prod et désactiver Ivy dans la configuration de construction,
2. Mettez à jour votre tsconfig.json dans la racine de l'espace de travail (ou vscode ne le comprendra pas ...) pour ajouter un mappage de chemin vers ce package, pointant vers le répertoire source du package.
3. Importez le package dans le code de l'application comme s'il provenait de node_modules, ie import {whatever} from 'happy-library';

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

Ce n'est pas parfait, mais au moins je peux utiliser ma propre bibliothèque dans une application Ivy de bout en bout, également créée par moi, sans les erreurs de vscode, tout en partageant l'amour et en la publiant sur NPM pour d'autres utilisateurs, et je ne pas avoir à constamment lien yarn / npm et déboguer pourquoi ALS ne fonctionne pas.

Intéressé par les commentaires si j'ai manqué quelque chose ...

PS: repo entièrement fonctionnel avec cette méthode sur https://github.com/abdes/happy-coding

Des progrès ont-ils été accomplis à ce sujet.

Il semble que cela soit disponible pour des tests bêta sur Angular 11 prévus pour novembre.

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

J'exécute sur Angular 11 dans mon projet (bibliothèque également construite avec Angular 11, avec l'indicateur --prod), et j'ai le problème décrit par npm install , Angular Language Service ne reconnaît pas mes composants exportés provenant de ma bibliothèque. On dirait que c'est un problème depuis très longtemps maintenant, quand pouvons-nous nous attendre à ce qu'il soit résolu?

Je pense que je vais finir par supprimer l'extension VSCode pour le moment, mais je vais perdre un développement puissant juste à cause de cela ...

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

@JonWallsten Merci, donc il sortira bientôt si je comprends bien

Ce problème a été corrigé par le nouveau service de langue native Ivy, publié dans la

Super travail, @kyliau!
Je vois beaucoup de nouvelles erreurs dans le modèle en ce qui concerne la vérification stricte des null et telles que nous avons manqué, vraiment sympa!

@kyliau Hmmmm ... c'est bizarre. J'avais le même problème avec une directive déclarée dans une bibliothèque et je l'ai résolu en suivant la suggestion de construire la bibliothèque avec le commutateur --prod. Le fait est que je suis déjà sur ALS 11.1.1 , donc théoriquement cela ne devrait plus être un problème, non?
Le projet est un multi-projet CLI standard, avec quelques bibliothèques et une application.
Pas sûr de la liaison npm ... Je n'ai rien fait de spécial. Le chemin de la bibliothèque est répertorié dans la racine tsconfig.json.

J'ai le même problème. Je construis ma bibliothèque avec le drapeau --prod , de sorte que ivy est désactivé.
Lié le dossier dist de la bibliothèque, lié le package à mon application et importé le libmodule. Mais toujours cette erreur, que ce n'est pas un élément angulaire connu.
Le composant de la bibliothèque se trouve dans le tableau declarations et dans le tableau exports .

Le composant s'affiche, mais obtient toujours cette erreur dans vscode. versions testées:

11.1.3
11.2.1
0,1100,4

Je suis d'accord, cela ne devrait probablement pas être fermé @kyliau ... J'ai un exemple minimal reproductible que j'ai fait pour un autre problème qui pourrait servir à démontrer celui-ci également. Jetez un œil à ceci: https://github.com/vicatcu/monorepo-example-error (publié à l'origine en relation avec ce message SO )

J'irai un peu plus loin, si j'ajoute l'option "enableIvy": false sous angularCompilerOptions dans le tsconfig.lib.json propos de ce commentaire , comme je l'ai fait sur cette branche de mon exemple de repo , mes erreurs disparaissent dans vscode (étant donné que mon exemple de projet est toujours cassé d'une manière que je ne comprends pas)

Juste pour clarifier, être sur v11.1.x ne suffit pas, vous devez activer le mode Ivy en suivant les instructions ici .
Vous ne devriez pas avoir à changer votre tsconfig.*.json .
Le fait que ... is not a known angular element apparaisse signifie que vous n'êtes pas en mode Ivy.
Pour déterminer le mode dans lequel vous vous trouvez, accédez au panneau Output et recherchez le service de langage Angular. Il devrait mentionner Ivy. (voir capture d'écran ci-dessous).
Votre projet n'a pas besoin d'utiliser Ivy pour utiliser le service de langue Ivy, mais vous devez utiliser Angular> = v9.

Si après avoir vérifié tout ce qui précède et que l'extension ne fonctionne toujours pas comme prévu, veuillez ouvrir un nouveau problème pour nous aider à trier et réduire le bruit. Merci beaucoup!

@kyliau merci, pour ma part, j'avais certainement raté ça.