Apicurio-studio: AsyncAPI: editar um canal no editor de origem causa uma referência circular

Isso deve ser resolvido por https://github.com/Apicurio/apicurio-data-models/pull/309

Oi,

Obrigado. Precisaríamos ter o 1.1.14 usado no estúdio, a fim de completar a correção do bug. Você poderia reabrir?

Atenciosamente,

OK, eu atualizei apicurio-data-models para 1.1.14 em pom.xml e package.json . Existe mais para consertar isso do que isso?

Um comando add é criado ali, em vez de substituir.

Eu estava trabalhando nisso (+ implementando cloneChannel), mas comecei a encontrar esses erros https://github.com/Apicurio/apicurio-studio/runs/3402960785#step : 4: 21009

Eu realmente não vejo nada entre 1.1.13 e 1.1.14 , talvez uma regressão após a atualização do jsweet?

Acredito ter corrigido os erros aos quais você vinculou acima. O fluxo de trabalho ainda está em andamento, então saberemos assim que terminar. Mas minha correção funcionou localmente.

Acho que ainda há alguns problemas de tempo de execução após a atualização, algo trava no pacote js quando tento acessar o painel e parece que Oas30PathItem está indefinido quando precisa ser estendido

89556eff82a3e9894f3672f07959e6e2d871db15

3eac2b5c

OK, vou precisar me aprofundar nisso - pode ser uma regressão JSweet. Não tenho certeza...

Fiz um pequeno progresso nisso - confirmei que é uma regressão JSweet. Se eu reverter as versões JSweet e Java (e não fizer outras alterações), posso carregar a biblioteca no navegador sem problemas.

Vou examinar as diferenças na saída de JSweet 2 para JSweet 3 ...

O problema parece ser um problema que relatei ao JSweet ano passado: https://github.com/cincheo/jsweet/issues/628

Nessa edição, menciono que a única diferença material que pude encontrar na saída gerada é a localização de algumas das import instruções. Na nova versão, algumas das importações não estavam na parte superior do arquivo, mas sim na parte inferior.

Escrevi um pós-processador que tentará corrigir o problema reorganizando as importações nos arquivos TS gerados pelo JSweet para que estejam sempre no topo. Mas, surpreendentemente, não fez diferença.

Em última análise, acho que o problema é que temos algumas referências circulares no modelo de dados. Especificamente porque o próprio OpenAPI tem algumas referências circulares. Por exemplo:

Oas30PathItem -> Oas30Operation -> Oas30Callback -> Oas30CallbackPathItem -> Oas30PathItem

E também:

Oas30MediaType -> Oas30Encoding -> Oas30Header -> Oas30MediaType

Não sei por que eles não eram problemáticos no JSweet 2.3.5, mas agora são problemáticos no 3.x. Ainda estou tentando descobrir isso. Tudo funciona (incluindo todos os nossos testes baseados em Jest) até que o JS transpilado seja agrupado usando rollup. Nesse ponto, a ordem do pacote UMD (a ordem em que os arquivos .js individuais são agrupados no UMD) é diferente ao usar JSweet 3 vs. JSweet 2. Não consigo descobrir o que acontece com o o código gerado é diferente, o que faria com que o rollup o agrupasse de maneira diferente. É muito frustrante.

Por enquanto, vou reverter apicurio-data-models de volta para Java 8 e JSweet 2.3.5 e fazer outro lançamento. Dessa forma, teremos pelo menos uma biblioteca de modelos de dados funcionando e podemos fazer progressos no Studio novamente.

À parte : acho que para o Apicurio Data Models 2.x vou precisar repensar um pouco a organização dos próprios modelos, para tentar evitar referências circulares de classe. Ainda não decidi como isso ficará, mas talvez mais uso de interfaces para os modelos ajude.

Liberando modelos de dados 1.1.15 agora. Depois disso, irei atualizá-lo no Studio e espero que possamos fazer progressos nisso.

OK, isso é feito. Os testes de fumaça passam. Por favor, tente novamente e vamos ver como estamos nos saindo. :)

Parece certo, enviei a correção junto com algumas outras coisas que vi durante o teste