Atualizar. O compilador Ivy não cria o arquivo lib-name.metadata.json em project_root/dist/lib-name .
Será esse o problema?

+1 eu tenho o mesmo problema

Após a versão 9, vamos mudar os serviços internos de linguagem para usar o compilador Ivy. Até então, o serviço de linguagem precisaria contar com metadata.json para recuperar informações adicionais sobre uma diretiva.

Sim, este é o problema. Para resolver por enquanto, você precisará construir a versão prod de sua biblioteca que tem "enableIvy": false em tsconfig. Isso então gera o arquivo de metadados necessário na pasta dist.

ou seja, ng build lib-component --prod

Mas você também precisa certificar-se de Restart Angular Language service após cada compilação no vs-code.

Todas essas informações não são facilmente encontradas entre o plugin vs-code e o próprio angular. Apenas um alerta para qualquer outra pessoa com esse mesmo problema.

Minha suposição de que

• https://github.com/angular/vscode-ng-language-service/issues/340 e
• https://github.com/angular/vscode-ng-language-service/issues/457
  estão todos relacionados.

@jiverson em relação à sua solução alternativa ng build lib-component --prod para mim produz um erro An unhandled exception occurred: Configuration 'production' is not set in the workspace. e eu vi evidências em outros lugares de que o sinalizador --prod para bibliotecas não é mais relevante. Estou usando @ angular / cli v8.3.25 embora ... embora este problema tenha sido referido como uma possível duplicata para # 665, não tenho certeza se é. Alguma ideia? / cc @ayazhafiz

Alguma atualização sobre isso? Temos nossas próprias bibliotecas desenvolvidas e publicadas em ivy, mesmo em prod.

O trabalho está em andamento para mover o serviço de idiomas para um back-end Ivy!

Posso confirmar que se você:

• construir biblioteca com ng build my-library --prod e
• ctrl + shift + p e então selecione "Reiniciar servidor Angular Language"

o (s) erro (s) do tipo "'xyz' não é um elemento conhecido" será removido do projeto pai da biblioteca.

Pelo que entendi, é porque --prod irá (entre outras coisas) gerar my-library.metadata.json arquivo na pasta dist que será então usado pelo servidor de linguagem para reconhecer os seletores de componentes definidos na minha biblioteca.

Agora, seria de se esperar que se eu npm publish biblioteca construída com ng build my-library --prod e então npm install aquela biblioteca em algum outro aplicativo Angular, o servidor de linguagem veria o arquivo de metadados instalado pacote npm (na pasta node_modules ) e não relataria "'xyz' não é um elemento conhecido".

No entanto, isso não está funcionando como esperado e eu posso ver o mesmo erro em um projeto que tem npm install ed minha biblioteca, mesmo que não haja um arquivo de metadados json presentes na pasta minha biblioteca em node_modules.

Seria o mesmo bug deste problema ou um bug diferente?

Ou existe alguma outra combinação mágica (ou adicional) de teclas para pressionar ou comandos para fornecer ao servidor de linguagem para que ele processe npm install ed bibliotecas Angular corretamente?

Parece que a nova maneira de Ivy trabalhar é confiar nos metadados dos arquivos .d.ts e não mais nos arquivos metadat.json. A única razão pela qual uma compilação --prod está funcionando é porque seu tsconfig está definindo enableIvy como false (conforme recomendado pelo angular para bibliotecas publicadas npm). Este é um problema de serviço de idioma e não um problema de clique angular, pois a compilação funcionará bem com ou sem Ivy para um aplicativo que usa a biblioteca publicada.

O problema é duplo:

1. Ivy remove os arquivos metadata.json, exigidos pelo ALS e outras ferramentas também
2. ALS não é atualmente inteligente o suficiente para obter as informações de metadados Ivy em vez de .metadata.json

Por que esse é um problema muito chato?

• Ivy é o caminho a seguir, e os desenvolvedores de bibliotecas também o farão,
• ao criar uma biblioteca em seu projeto de aplicativo baseado em Ivy, você ainda deseja usar Ivy de ponta a ponta em seu aplicativo, ao mesmo tempo em que é um bom cidadão e publica sua biblioteca reutilizável no npm para que outros a usem.
• a maioria dos desenvolvedores usa o link npm ou aponta o tsconfig para o diretório dist da biblioteca para importações durante o desenvolvimento do aplicativo, essa é a maneira óbvia de qualquer maneira,
• é irritante como o inferno ter vscode sinalizando coisas em sua biblioteca como desconhecidas,

Aqui está o que acabei fazendo para contornar esse problema, que pode ser aceitável para algumas pessoas nas mesmas circunstâncias. Não ajudará as pessoas que desejam usar suas bibliotecas publicáveis ​​nas mesmas condições que um usuário de tais bibliotecas (ou seja, do pacote npm publicado):

Supondo que você esteja usando um monorepo ou estrutura semelhante em que o código-fonte da biblioteca publicável esteja acessível de maneira consistente para o aplicativo que o usa.

Vamos supor que o pacote se chama 'happy-library' ...

1. Compile (com --prod) e publique o pacote da biblioteca no npm como de costume. Você deve usar --prod e ter Ivy desativado na configuração de construção,
2. Atualize seu tsconfig.json na raiz do espaço de trabalho (ou vscode não descobrirá ...) para adicionar um mapeamento de caminho para esse pacote, apontando para o diretório de origem do pacote.
3. Importe o pacote no código do aplicativo como se fosse de node_modules, ou seja, import {whatever} from 'happy-library';

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

Não é perfeito, mas pelo menos posso usar minha própria biblioteca em um aplicativo Ivy end-to-end, também feito por mim, sem os erros de vscode, enquanto ainda compartilho o amor e publico no NPM para outros usuários, e eu não precisa constantemente fazer o link yarn / npm e depurar porque o ALS não está funcionando.

Interessado no feedback se eu tiver perdido algo ...

PS: repo totalmente funcional com este método em https://github.com/abdes/happy-coding

Algum progresso foi feito nisso.

Parece que estará disponível para teste beta no Angular 11 agendado para novembro.

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

Estou executando o Angular 11 em meu projeto (biblioteca construída também com o Angular 11, com o sinalizador --prod) e tenho o problema descrito por @nprasovict . Publiquei minha biblioteca em pacotes Gitlab e quando a instalo em nosso projeto com npm install , o Angular Language Service não reconhece meus componentes exportados vindos de minha biblioteca. Parece que já é um problema há muito tempo, quando podemos esperar que seja resolvido?

Acho que vou acabar removendo a extensão VSCode por enquanto, mas estarei perdendo um desenvolvimento poderoso só por causa disso ...

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

@JonWallsten Obrigado, então será lançado em breve se eu entender bem

Isso foi corrigido pelo novo serviço de idioma nativo da Ivy, lançado na v11.1.0 .

Ótimo trabalho, @kyliau!
Vejo muitos erros novos no modelo quando se trata de verificação de nulos estrita e que não percebemos, muito bom!

@kyliau Hmmmm ... isso é estranho. Eu estava tendo o mesmo problema com uma diretiva declarada em uma biblioteca e resolvi seguindo a sugestão de construir a biblioteca com a opção --prod. O fato é que já estou no ALS 11.1.1 , então, teoricamente, isso não teria que ser mais um problema, certo?
O projeto é um multiprojeto CLI regular, com algumas bibliotecas e um aplicativo.
Não tenho certeza sobre o link npm ... Eu não fiz nada de especial. O caminho da biblioteca está listado na raiz tsconfig.json.

Eu tenho o mesmo problema. Eu construo minha biblioteca com a bandeira --prod , de modo que a ivy seja desativada.
Vinculei a pasta dist da biblioteca, vinculei o pacote ao meu aplicativo e importei o libmodule. Mas ainda obtendo este erro, que não é um elemento angular conhecido.
O componente da biblioteca está no declarations e no array exports .

O componente é exibido, mas ainda obtém este erro no vscode. versões testadas:

11.1.3
11.2.1
0,1100,4

Eu concordo, isso provavelmente não deveria ser fechado @kyliau ... Eu tenho um exemplo reproduzível mínimo que fiz para outro problema que pode servir para demonstrar este também. Dê uma olhada nisso: https://github.com/vicatcu/monorepo-example-error (postado originalmente em conexão com este post do SO )

Darei um passo adiante, se adicionar a opção "enableIvy": false sob angularCompilerOptions no tsconfig.lib.json propósito deste comentário , como fiz neste branch do meu repositório de exemplo , meus erros desaparecem em vscode (dado que meu projeto de exemplo ainda está quebrado de alguma forma que não entendo)

Só para esclarecer, estar em v11.1.x não é suficiente, você deve habilitar o modo Ivy seguindo as instruções aqui .
Você não deve ter que mudar seu tsconfig.*.json .
O fato de ... is not a known angular element aparecido significa que você não está no modo Ivy.
Para determinar em qual modo você está, vá para o painel Output e procure o serviço de idioma Angular. Deve mencionar Ivy. (veja a imagem abaixo).
Seu projeto não precisa estar usando Ivy para usar o serviço de linguagem Ivy, mas você precisa usar Angular> = v9.

Se, depois de verificar todos os itens acima, a extensão ainda não funcionar como esperado, abra um novo problema para nos ajudar a fazer a triagem e reduzir o ruído. Muito obrigado!

@kyliau obrigado. Eu, por exemplo, certamente tinha sentido falta disso.