Barista: Mover construtores personalizados para plug-ins Nx

Criado em 19 fev. 2020  ·  8Comentários  ·  Fonte: dynatrace-oss/barista

Solicitação de recurso

Mova nossos construtores personalizados para plug-ins Nx:

https://github.com/nrwl/nx/commit/fe98e29#diff -9e66bea35c8c76309609c9218bc259c4R30

Os plug-ins são a forma oficial como devemos lidar com nossos construtores e ferramentas inteiras.

P2 feature no-issue-activity

Comentários muito úteis

Está bem então. Pelo que entendi a explicação que @ ffriedl89 me deu:

  • Tivemos que mover todas as nossas ferramentas para a pasta libs para # 570 porque nx tem caminhos codificados de apps e libs em sua regra de limite de linting
  • Como movemos as ferramentas para libs agora, outras regras de linting de nx falham, porque não permitem arquivos adicionais em sua libraryRoot (ou seja, Dockerfile, ect. _Files dos quais dependemos em algumas ocasiões de ferramenta_)
  • O Nx fornece com a versão 9 uma nova solução para estes, porque aparentemente notaram que há necessidade de ferramentas adicionais. E a maneira de fazer isso é adicionar o conjunto de ferramentas (que não deve ser considerado uma biblioteca) em uma pasta de plug-ins onde o lint é menos estrito.

Todos 8 comentários

Estou questionando por que precisaremos fazer isso. Existe uma dor que estamos resolvendo com este? Pelo que posso ver, as ferramentas que temos agora funcionam. Quais são os benefícios que ganhamos ao reescrever todas as nossas ferramentas para plug-ins nrwl?

não reescrever - é mais como ele está integrado no espaço de trabalho nx. Deve ser mais uma biblioteca de conversão para plugin. Então, podemos nos livrar da maneira "hacky" como nossos próprios construtores estão sendo construídos.
com tsc --outdir /node_modules/dynatrace/barista-builders por exemplo

Devemos sempre seguir as orientações de nx porque é uma estrutura de pasta opinativa e, caso contrário, o conjunto de ferramentas não funciona conforme o esperado

Por favor, corrija-me se eu estiver errado aqui, mas atualmente o ferramental funciona conforme o esperado, não é?

não. Encontramos problemas com arquivos que não são importados e copiados de ferramentas, onde esmagamos nosso gráfico de dependência. Nossas ferramentas não são bibliotecas, mas não ferramentas no significado de nrwl / nx. Eles são plug-ins, portanto, devemos tratá-los como um só. Isso deve ser resolvido após as refatorações do espaço de trabalho @ ffriedl89 .

Está bem então. Pelo que entendi a explicação que @ ffriedl89 me deu:

  • Tivemos que mover todas as nossas ferramentas para a pasta libs para # 570 porque nx tem caminhos codificados de apps e libs em sua regra de limite de linting
  • Como movemos as ferramentas para libs agora, outras regras de linting de nx falham, porque não permitem arquivos adicionais em sua libraryRoot (ou seja, Dockerfile, ect. _Files dos quais dependemos em algumas ocasiões de ferramenta_)
  • O Nx fornece com a versão 9 uma nova solução para estes, porque aparentemente notaram que há necessidade de ferramentas adicionais. E a maneira de fazer isso é adicionar o conjunto de ferramentas (que não deve ser considerado uma biblioteca) em uma pasta de plug-ins onde o lint é menos estrito.

@tomheller resumo perfeito: D

Este problema está desatualizado porque está aberto há 30 dias sem atividades. Remova o rótulo ou comentário desatualizado ou será fechado em 5 dias

Este problema está desatualizado porque está aberto há 90 dias sem atividades. Remova o rótulo ou comentário desatualizado ou será fechado em 5 dias

Esta página foi útil?
0 / 5 - 0 avaliações