Olá,
Na versão mais recente, o formatador message
não funciona, infelizmente. Isso acontece em master
, o que é uma ótima notícia. Seria um bom momento para um lançamento? :)
Obrigada 💜
Olá @sroze - você testou as mensagens geradas com algum consumidor? Se sim, quais são?
Gostaria de ter certeza de que a saída gerada funcione com o seguinte:
@ vincent-psarga - podemos atualizar o cck para validar isso como parte da compilação do monorepo?
O seguinte deve ser atualizado antes de cortar um lançamento:
"cucumber-expressions": "^8.3.0"
-> "@cucumber/cucumber-expressions": "^10.2.0"
"cucumber-messages": "^8.0.0"
-> "@cucumber/messages": "^12.1.1"
"cucumber-tag-expressions": "^2.0.3"
-> "@cucumber/tag-expressions": "^3.0.0"
"gherkin": "^9.0.0"
-> "@cucumber/gherkin": "^13.0.0"
Se um lançamento fosse feito sem essas atualizações, as mensagens produzidas pelo formatador message
seriam incompatíveis com os lançamentos mais recentes de cucumber-html
, json-formatter
e qualquer outra coisa que dependa do versão mais recente de @cucumber/messages
. E isso não seria útil para ninguém, eu acho.
@aslakhellesoy Na verdade, estou usando-os com meu próprio analisador para integrá-los em uma documentação gerada automaticamente (em um plugin para mkdocs), então estou usando --format message:output.ndjson
e lendo aquele arquivo output.ndjson
. Até agora tudo bem, muito melhor do que a saída JSON anterior, devo dizer 👌
@ vincent-psarga - podemos atualizar o cck para validar isso como parte da compilação do monorepo?
Apenas para ter certeza de que entendi isso corretamente: execute a versão mais recente xxx-formatter
contra a versão de messages
para garantir que não pulamos uma versão dos formatadores?
Isso definitivamente faz sentido. Embora eu não saiba se isso deve ser parte do CCK ou um segundo trabalho de CI para cada formatador.
@sroze muito legal! Lembre-se de que houve algumas alterações incompatíveis com versões anteriores na biblioteca @cucumber/messages
de 8.0.0
para 12.1.1
. Ele também foi renomeado. Qualquer biblioteca que dependa dela também terá que ser atualizada.
As outras implementações do Cucumber (JVM / Java e Ruby) usam as versões mais recentes da biblioteca de mensagens, portanto, sua ferramenta não seria capaz de consumi-las.
@sroze , você tem um link para seu projeto?
@ vincent-psarga Eu estava sugerindo que pudéssemos verificar se o cucumber.js é compatível com nosso cck. Teríamos que implementar definições de etapas, executar cucumber.js com o formatador de mensagem e, em seguida, verificar se ambos formatador json e formatador html podem consumir essas mensagens.
Já não estamos fazendo isso para pepino-rubi e pepino-jvm?
Ah ok, não vi que estávamos no repo cucumber-js
(esse é o problema ao verificar as notificações no telefone ...).
Acho que seria possível, mas não tenho certeza se devemos fazer no próprio monorepo, mais neste repositório. Para ruby, temos duas validações feitas contra o CCK:
cucumber-ruby
, que valida pepino-rubi mestre em relação ao último lançamento de mensagens (mas usa o mestre de json-formatter
e html-formatter
)cucumber-ruby
. Ele teve que ser desativado, pois havia discrepâncias entre a versão de mensagens suportadas do pepino-ruby (poderia ser reativado, mas teria que ser desativado novamente após o próximo lançamento de mensagens)E, pelo que me lembro, as etapas de JS já estão implementadas para produzir o NDJson dourado com fake-cucumber
, então esta parte está quase pronta (apenas as importações podem ter que ser atualizadas)
@aslakhellesoy Estou trabalhando no # 1318 agora, que adiciona validação contra CCK e atualizações para os maxixe mais recentes, mensagens etc. Apenas trabalhando nas lacunas restantes, não faltam muito - com o objetivo de terminar nos próximos dias. Acho que estaremos em boa forma para lançar o 7.0.0 depois disso.
Eu queria verificar sua intenção com o pacote javascript CCK, na verdade - percebi que ele foi publicado no npm em @cucumber/compatibility-kit
há um tempo, mas não é atualizado há algum tempo. Por enquanto, estou apenas copiando os arquivos do monorepo para trabalhar, mas ter os recursos CCK e os acessórios de mensagem como uma dependência parece uma boa maneira de fazer isso.
Obrigado @davidjgoss , ansioso para poder usar a nova versão. Enquanto isso está sendo feito, é o que tenho que fazer para usar a versão master
de cucumber-js
. O principal desafio é que toda vez que executo npm i
novamente, npm
reclama que node_modules/cucumber
é um repositório Git. Você conhece uma maneira melhor? 🤔
diff --git a/package.json b/package.json
index e78cd20..8702cb7 100644
--- a/package.json
+++ b/package.json
@@ -30,7 +30,8 @@
"typeorm": "ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli.js -f src/orm-migratio
ns-config.ts",
"typeorm:migrate": "ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli.js -f src/orm-
migrations-config.ts migration:run",
"typeorm:revert": "ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli.js -f src/orm-m
igrations-config.ts migration:revert",
- "pod:migrate": "node ./node_modules/typeorm/cli.js -f dist/orm-migrations-config.js migration:run"
+ "pod:migrate": "node ./node_modules/typeorm/cli.js -f dist/orm-migrations-config.js migration:run",
+ "postinstall": "cd node_modules && mv cucumber cucumber-old && git clone https://github.com/cucumber/cucumber-js && mv cucumber-js cucumber && cd cucumber && npm i && npm run build-local && cd ../.."
},
"dependencies": {
@@ -86,7 +87,7 @@
"@typescript-eslint/eslint-plugin": "^3.4.0",
"@typescript-eslint/parser": "^3.4.0",
"common-tags": "^1.8.0",
- "cucumber": "^6.0.5",
+ "cucumber": "cucumber/cucumber-js#master",
"cucumber-pretty": "^6.0.0",
"cucumber-tsflow": "^3.2.0",
"eslint": "^7.3.1",
Posso ser chato e perseguir o seguinte para cortar um lançamento?
testResult
-> testStepResult
)Na verdade, cortamos um release @sroze. Experimente @cucumber/cucumber
- este é um pré-lançamento. Consulte o guia de migração para saber como atualizar.
Ótimo, vou tentar, obrigado! Não sabia porque nenhuma tag foi enviada 🙃
Obrigado pelo aviso @sroze - eu realmente tinha esquecido de empurrar a tag. Já acabou.
Alguma ideia sobre um pacote como este para ajudar mais pessoas a descobrir a nova versão?
7.0.0 foi lançado, consulte o changelog para obter instruções de migração. Obrigado!
Comentários muito úteis
@aslakhellesoy Estou trabalhando no # 1318 agora, que adiciona validação contra CCK e atualizações para os maxixe mais recentes, mensagens etc. Apenas trabalhando nas lacunas restantes, não faltam muito - com o objetivo de terminar nos próximos dias. Acho que estaremos em boa forma para lançar o 7.0.0 depois disso.
Eu queria verificar sua intenção com o pacote javascript CCK, na verdade - percebi que ele foi publicado no npm em
@cucumber/compatibility-kit
há um tempo, mas não é atualizado há algum tempo. Por enquanto, estou apenas copiando os arquivos do monorepo para trabalhar, mas ter os recursos CCK e os acessórios de mensagem como uma dependência parece uma boa maneira de fazer isso.