Cucumber-js: L'heure d'une sortie ? Le formateur `message` ne fonctionne pas dans la dernière version mais fonctionne sur `master`

Créé le 22 juin 2020  ·  14Commentaires  ·  Source: cucumber/cucumber-js

Salut,

Dans la dernière version, le formateur message ne fonctionne malheureusement pas. C'est le cas dans master , ce qui est une excellente nouvelle. Serait-ce le bon moment pour une sortie ? :)

Merci

fixed-in-7

Commentaire le plus utile

@aslakhellesoy Je travaille actuellement sur le #1318, ce qui ajoute une validation par rapport à CCK et des mises à jour des derniers cornichons, messages, etc. Je pense que nous serons en bonne forme pour sortir la 7.0.0 après cela.

En fait, je voulais vérifier votre intention avec le package javascript CCK - j'ai remarqué qu'il avait été publié sur npm sous @cucumber/compatibility-kit quelque temps mais qu'il n'avait pas été mis à jour depuis un moment. Pour l'instant, je ne fais que copier des fichiers du monorepo pour y travailler, mais avoir les fonctionnalités CCK et les appareils de message en tant que dépendance semble être une bonne façon de le faire.

Tous les 14 commentaires

Salut @sroze - avez-vous testé les messages générés avec des consommateurs ? Si oui, lesquels?

Je voudrais m'assurer que la sortie générée fonctionne avec les éléments suivants :

@vincent-psarga - pouvons-nous mettre à jour le cck pour le valider dans le cadre de la construction monorepo ?

Les éléments suivants doivent être mis à niveau avant de couper une version :

  • "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"

Si une version devait être faite sans ces mises à jour, les messages produits par le formateur message seraient incompatibles avec les dernières versions de cucumber-html , json-formatter et tout ce qui repose sur le dernière version de @cucumber/messages . Et ça ne servirait à personne je pense.

@aslakhellesoy Je les utilise en fait avec mon propre analyseur pour les intégrer dans une documentation générée automatiquement (dans un plugin pour mkdocs) donc j'utilise --format message:output.ndjson et je lis ce fichier output.ndjson . Jusqu'ici tout va bien, bien mieux que la précédente sortie JSON je dois dire

@vincent-psarga - pouvons-nous mettre à jour le cck pour le valider dans le cadre de la construction monorepo ?

Juste pour être sûr d'avoir bien compris : exécutez la dernière version xxx-formatter contre la version de messages pour vous assurer que nous ne sautons pas une version des formateurs ?
Cela a certainement du sens. Bien que je ne sache pas si cela devrait faire partie du CCK ou d'un deuxième travail CI pour chaque formateur.

@sroze très cool ! Gardez à l'esprit qu'il y a eu des modifications rétrocompatibles dans la bibliothèque @cucumber/messages de 8.0.0 à 12.1.1 . Il a également été renommé. Toute bibliothèque qui en dépend devra également être mise à jour.

Les autres implémentations de Cucumber (JVM/Java et Ruby) utilisent les dernières versions de la bibliothèque de messages, votre outil ne pourrait donc pas les utiliser.

@sroze as -tu un lien vers ton projet ?

@vincent-psarga Je suggérais que nous puissions vérifier que cucumber.js est conforme à notre cck. Nous devrions implémenter des définitions d'étapes, exécuter cucumber.js avec le formateur de messages, puis vérifier si json-formatter et html-formatter peuvent utiliser ces messages.

Ne le faisons-nous pas déjà pour le concombre-ruby et le concombre-jvm ?

Ah ok je n'avais pas vu qu'on était dans le cucumber-js repo (c'est le problème lors de la vérification des notifications sur le téléphone...).

Je suppose que ce serait faisable, mais je ne suis pas sûr que nous devrions le faire dans le monorepo lui-même, plus dans ce référentiel. Pour ruby, nous avons deux validations exécutées sur le CCK :

  • un fait dans cucumber-ruby , qui valide le maître cucumber-ruby par rapport à la dernière version des messages (mais utilise le maître de json-formatter et html-formatter )
  • un fait dans le monorepo, qui utilise le maître des messages actuel et la dernière version de cucumber-ruby . Il a dû être désactivé car il y avait des divergences entre la version des messages pris en charge de cucumber-ruby (il pourrait être réactivé mais devrait être à nouveau désactivé après la prochaine version des messages)

Et pour autant que je me souvienne, les étapes JS sont déjà implémentées pour produire le NDJson doré avec fake-cucumber , donc cette partie est presque terminée (seules les importations devront peut-être être mises à jour)

@aslakhellesoy Je travaille actuellement sur le #1318, ce qui ajoute une validation par rapport à CCK et des mises à jour des derniers cornichons, messages, etc. Je pense que nous serons en bonne forme pour sortir la 7.0.0 après cela.

En fait, je voulais vérifier votre intention avec le package javascript CCK - j'ai remarqué qu'il avait été publié sur npm sous @cucumber/compatibility-kit quelque temps mais qu'il n'avait pas été mis à jour depuis un moment. Pour l'instant, je ne fais que copier des fichiers du monorepo pour y travailler, mais avoir les fonctionnalités CCK et les appareils de message en tant que dépendance semble être une bonne façon de le faire.

Merci @davidjgoss , au plaisir de pouvoir utiliser la nouvelle version. Pendant que cela est fait, voici ce que je dois faire pour utiliser la version master de cucumber-js . Le principal défi est que chaque fois que je relance npm i , npm plaint que node_modules/cucumber est un dépôt Git. Connaissez-vous une meilleure façon? ??

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",

Puis-je être ennuyeux et poursuivre ce qui suit pour couper une version ?

  1. @aslakhellesoy les dépendances ont bien été mises à jour.
  2. ✅ Le travail (massif) de testResult -> testStepResult )

Nous avons en fait coupé une version @sroze. Essayez @cucumber/cucumber - ceci est une préversion. Voir le guide de migration pour savoir comment mettre à jour.

Oh super, je vais essayer, merci ! Je ne savais pas car aucun tag n'a été poussé

Merci pour le heads-up @sroze - j'avais en effet oublié de pousser le tag. C'est parti maintenant.

Avez-vous des idées sur un package comme celui-ci pour aider plus de personnes à découvrir la nouvelle version ?

7.0.0 est maintenant publié, consultez le journal des modifications pour les instructions de migration. Merci!

Cette page vous a été utile?
0 / 5 - 0 notes