更新。 Ivyコンパイラはproject_root/dist/lib-nameファイルlib-name.metadata.jsonを作成しません。
これが問題でしょうか？

+1同じ問題があります

バージョン9以降では、Ivyコンパイラを使用するように言語サービスの内部を切り替えます。 それまでは、言語サービスはmetadata.jsonに依存してディレクティブに関する追加情報を取得する必要がありました。

はい、これが問題です。 当面解決するには、tsconfigに"enableIvy": falseを含むライブラリのprodバージョンをビルドする必要があります。 これにより、distフォルダーに必要なメタデータファイルが生成されます。

つまりng build lib-component --prod

ただし、vs-codeをビルドするたびに、必ずRestart Angular Language serviceにする必要があります。

このすべての情報は、vs-codeプラグインとangular自体の間で簡単に見つけることはできません。 この同じ問題を経験している他の人に注意してください。

私の仮定

• https://github.com/angular/vscode-ng-language-service/issues/340および
• https://github.com/angular/vscode-ng-language-service/issues/457
  すべて関連しています。

回避策ng build lib-component --prodに関する@jiversonは、エラーAn unhandled exception occurred: Configuration 'production' is not set in the workspace.を生成し、ライブラリの--prodフラグが関連しなくなったという証拠を他の場所で見ました。 私は@angular / cli v8.3.25を使用していますが、この問題は＃665の重複の可能性があると言われていますが、それが正しいかどうかはわかりません。 何かご意見は？ / cc @ayazhafiz

これに関する更新はありますか？ 私たちは独自のライブラリを開発し、prodでもivyで公開しています。

言語サービスをIvyバックエンドに移行する作業が進行中です！

あなたがそうするならば、私はそれを確認することができます：

• ng build my-library --prodライブラリをビルドし、
• ctrl + shift + pを押してから、「AngularLanguageサーバーの再起動」を選択します

タイプ「 'xyz'は既知の要素ではありません」のエラーは、ライブラリの親プロジェクトから削除されます。

私が理解したように、これは--prodが（とりわけ） distフォルダーにmy-library.metadata.jsonファイルを生成し、言語サーバーが定義されたコンポーネントセレクターを認識するために使用するためです。 my-libraryで。

さて、 ng build my-library --prod構築されたnpm publishライブラリを他のAngularアプリにnpm installすると、言語サーバーはインストールされているメタデータファイルを見ると予想されます。 npmパッケージ（ node_modulesフォルダー内）であり、「 'xyz'は既知の要素ではありません」とは報告しません。

しかし、これは期待通りに動作していないと私は持っているプロジェクトで同じエラーを見ることができますnpm install node_modulesで私のライブラリフォルダ内のメタデータJSONファイルが存在していても、私のライブラリを編。

これは、この問題と同じバグですか、それとも別のバグですか？

または、押すキーや言語サーバーに与えるコマンドの魔法の組み合わせが他にあるので、 npm install ed Angularライブラリを正しく処理できますか？

Ivyが機能している新しい方法は、metadat.jsonファイルからではなく、.d.tsファイルからのメタデータに依存することであるようです。 --prodビルドが機能する唯一の理由は、tsconfigがenableIvyをfalseに設定しているためです（npmで公開されたライブラリのangularで推奨されています）。 公開されたライブラリを使用するアプリケーションのビルドはIvyの有無にかかわらず問題なく機能するため、これは言語サービスの問題であり、角度のあるcliの問題ではありません。

問題は2つあります。

1. Ivyは、ALSやその他のツールにも必要なmetadata.jsonファイルを削除します
2. ALSは現在、.metadata.jsonではなくIvyメタデータから情報を取得するほど賢くはありません

なぜこれが非常に厄介な問題なのですか？

• アイビーは行くべき道であり、ライブラリ開発者もそれを行く道にするでしょう、
• Ivyベースのアプリケーションプロジェクトでライブラリを作成するときは、良き市民でありながら、他の人が使用できるように再利用可能なライブラリをnpmに公開しながら、アプリでIvyをエンドツーエンドで使用する必要があります。
• ほとんどの開発者は、npmリンクを使用するか、アプリ開発中にインポートするためにtsconfigをライブラリのdistディレクトリにポイントします。これはとにかく明らかな方法です。
• ライブラリ内のアイテムに不明なフラグを立てるvscodeを使用するのは、非常に面倒です。

これが私がこの問題を回避するためにやったことです。これは同じ状況下で一部の人々に受け入れられるかもしれません。 公開可能なライブラリをそのようなライブラリのユーザーと同じ条件下で（つまり、公開されたnpmパッケージから）使用したい人には役立ちません。

公開可能なライブラリのソースコードに、それを使用するアプリケーションが一貫した方法でアクセスできるモノレポまたは同様の構造を使用していると仮定します。

パッケージが「happy-library」と呼ばれていると仮定しましょう...

1. （--prodを使用して）ビルドし、通常どおりライブラリパッケージをnpmに公開します。 --prodを使用し、ビルド構成でIvyを無効にする必要が
2. ワークスペースルートのtsconfig.jsonを更新して（またはvscodeがそれを理解しない...）、パッケージのソースディレクトリを指すパスマッピングをそのパッケージに追加します。
3. node_modulesからのものであるかのように、アプリケーションコードにパッケージをインポートします。つまり、 import {whatever} from 'happy-library';

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

完璧ではありませんが、少なくとも私が作成したエンドツーエンドのIvyアプリケーションで、vscodeのエラーなしに自分のライブラリを使用しながら、愛を共有して他のユーザーのためにNPMに公開することができます。常にyarn / npmリンクを作成し、ALSが機能しない理由をデバッグする必要はありません。

私が何かを逃したかもしれないならば、フィードバックに興味があります...

PS： https：//github.com/abdes/happy-codingでこのメソッドを使用して完全に機能するリポジトリ

これについては進展がありましたか。

これは、11月に予定されているAngular11でのベータテストに利用できるようです。

https://github.com/angular/vscode-ng-language-service/issues/335#issuecomment-693545000を参照して

私は自分のプロジェクトでAngular11を実行しています（ライブラリもAngular 11でビルドされ、-prodフラグが付いています）。 ます。 ライブラリをGitlabパッケージで公開しましたが、 npm installしてプロジェクトにインストールすると、Angular LanguageServiceはライブラリからエクスポートされたコンポーネントを認識しません。 非常に長い間問題になっているようですが、いつ解決されると期待できますか？

とりあえずVSCode拡張機能を削除することになると思いますが、これだけで強力な開発を失うことになります...

@schankam ： https ：

@JonWallstenありがとうございます。よく理解できればまもなくリリースされます

これは、 v11.1.0でリリースされた新しいIvy-native言語サービスによって修正され

素晴らしい仕事、@ kyliau！
厳密なnullチェックに関しては、テンプレートに多くの新しいエラーがあり、見逃してしまいました。本当に素晴らしいです。

@kyliauうーん...それは変だ。 ライブラリで宣言されたディレクティブでまったく同じ問題が発生していましたが、-prodスイッチを使用してライブラリを構築するという提案に従って問題を解決しました。 私はすでにALS11.1.1を使用しているので、理論的にはこれはもう問題になる必要はありませんよね？
このプロジェクトは通常のCLIマルチプロジェクトであり、いくつかのライブラリとアプリが含まれています。
npmのリンクについてはよくわかりません...私は特別なことは何もしませんでした。 ライブラリのパスは、ルートtsconfig.jsonにリストされています。

同じ問題があります。 --prodフラグを使用してライブラリをビルドし、ツタが無効になるようにします。
ライブラリのdistフォルダーをリンクし、パッケージをアプリにリンクして、libmoduleをインポートしました。 しかし、それでもこのエラーが発生します。これは、既知の角度要素ではないということです。
libのコンポーネントは、 declarationsとexports配列にあります。

コンポーネントは表示されますが、vscodeでこのエラーが発生します。 テスト済みバージョン：

11.1.3
11.2.1
0.1100.4

私は同意します、これはおそらく@kyliauで閉じられるべきではありません...私はこれを実証するのに役立つかもしれない別の問題のために私が作った最小限の再現可能な例を持っています。 これを見てください： //github.com/vicatcu/monorepo-example-error （元々はこのSO投稿に関連して投稿されました）

私の例のリポジトリのこのブランチで行ったtsconfig.lib.jsonのangularCompilerOptions下に"enableIvy": falseオプションを追加すると、このコメントが適切になります。 、私のエラーはvscodeで消えます（私のサンプルプロジェクトがまだ理解できない何らかの方法で壊れていることを認めました）

明確にするために、 v11.1.xを使用するだけでは不十分です。ます。
tsconfig.*.jsonを変更する必要はありません。
... is not a known angular elementが表示されたという事実は、アイビーモードではないことを意味します。
現在使用しているモードを確認するには、 Outputパネルに移動し、Angular言語サービスを探します。 アイビーについて言及する必要があります。 （下のスクリーンショットを参照）。
Ivy言語サービスを使用するためにプロジェクトでIvyを使用する必要はありませんが、Angular> = v9を使用する必要があります。

上記のすべてを確認しても拡張機能が期待どおりに機能しない場合は、新しい問題を開いて、トリアージとノイズの削減に役立ててください。 どうもありがとうございました！

@kyliauありがとう私は、確かにそれを見逃していました。