Mocha: désactivation des globaux

Même s'il venait de jeter ses conneries partout dans l'espace global lorsque vous require('mocha') , ce serait mieux que l'état actuel des choses.

Je ne pense pas que ce soit idiot, mais il y a des compromis avec tout. Je serais heureux avec quelque chose comme ça:

var Mocha = require('mocha');
var mocha = new Mocha(options);
mocha.describe('blah blah', function....

personne ne l'utiliserait, mais au moins ce serait une façon plus propre de mettre en œuvre ce que nous avons actuellement. Il y aurait une tonne de passe-partout que tout le monde devrait configurer à chaque fois, mais si nous pouvions les réduire aux API CLI-ish, ce serait bien. Même s'il y avait lib / cli.js qui vient de passer dans l'ARGV, mais je doute toujours que quiconque l'utilise, vous pouvez l'utiliser sans la CLI raisonnablement facile, mais cela montre que personne ne veut vraiment au-delà de certains cas extrêmes.

@visionmedia qui semble plutôt sympa. La raison pour laquelle j'ai suggéré require("mocha/bdd") ou similaire est que ce serait assez facile à implémenter en termes de Mocha existant, mais oui, le vôtre est probablement meilleur. (Vous pourriez envisager de l'utiliser pour, par exemple, exécuter plusieurs suites de tests à la fois ou quelque chose du genre. Eh bien, cela serait probablement interrompu à cause de l'utilisation de process.on ('uncaughtException'), mais vous voyez ce que je veux dire.)

Je peux essayer un pull request pour celui-ci un jour.

C'est un excellent exemple où un petit JavaScript futur via une affectation de déstructuration va un long chemin.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7#Destructuring_assignment_% 28Merge_into_own_page.2Fsection% 29

var [describe,it,beforeEach,afterEach] = new require("mocha")(options);

J'aimerais juste qu'il y ait un support d'harmonie des nœuds pour cela.

Est-ce l'idée de pouvoir faire

node test/a-mocha-test.js

Et a-t-il effectué ce test?

@glenjamin yup

Ayant essayé de le faire moi-même sur nodespec, le problème n'était pas vraiment de rendre les différentes fonctions disponibles, le problème était de savoir comment / quand commencer l'exécution - nous aurions toujours besoin d'une approche de définition / exécution en deux passes.

Les options que j'ai proposées étaient:
1) Demandez à chaque utilisateur d'ajouter quelque chose comme mocha.exec () au bas de chaque fichier qu'il pourrait vouloir exécuter de manière isolée
2) Attendez que core ajoute quelque chose comme process.on ('exit'), mais quand la boucle d'événements est toujours disponible
3) supposez que chaque fichier n'a qu'un seul bloc de description de niveau supérieur et commencez l'exécution lorsque cela se termine

(1) est probablement le plus beau, ce qui pourrait ressembler à ceci:

var run = require('mocha/required');

describe('blah blah' , function() {
// ..
});

run();

Cela ne semble pas ajouter grand-chose au fait node ./node_modules/.bin/_mocha test/a-mocha-test.js faire mocha .

Je pense que cela ne correspond plus à la façon dont le moka est actuellement utilisé. Comme ce fil est inactif depuis plus d'un an, je le ferme pour l'instant.

Si quelqu'un est toujours intéressé par cela, n'hésitez pas à commenter ou à proposer une pull-request et nous considérerons :)

Cela pourrait-il être rouvert? Cela m'intéresse toujours beaucoup. Ne pas pouvoir effectuer uniquement des tests de moka node test.js était l'une des principales raisons pour lesquelles mes collègues de Mapbox et moi-même avons abandonné le moka pour des harnais comme le ruban et le robinet. Personnellement, je préfère m'en tenir au moka, mais je trouve que l'argument de la "capacité de nœud" est quelque peu convaincant.

Edit: l'argument "node-ability" a été élaboré par @tmcw ici .

Pour plus de clarté, l'absence d'une interface require able n'est pas le principal bloqueur ici du point de vue de l'utilisateur. Ce qui suit est déjà documenté pour fonctionner:

var describe = require('mocha').describe;
var before = require('mocha').before;
var it = require('mocha').it;

Et ça devient plus agréable avec ES6:

import { describe, before, it } from 'mocha';

Le problème est que cela ne fonctionne que lors de l'exécution via le binaire mocha .

Oh, merci pour la clarification. :) Si nous offrons déjà cette capacité lors de l'exécution en utilisant le binaire mocha, je suis d'accord que ce serait bien de faire de même avec node. Je vais l'examiner. Merci!

Maintenant que ce nœud a un hook beforeExit, cela semble assez faisable.

Aurait besoin d'être quelque chose comme

var { describe, it } = require('mocha/auto')

Ouais. Comme TJ l'a dit, le problème est que même si nous devions rendre tout "compatible avec les nœuds", cela peut nécessiter trop de passe-partout pour être utile.

Pourtant...

@glenjamin merci pour le heads-up sur beforeExit . Je pense que nous pourrions en tirer parti. Les gens se plaindraient probablement encore que c'est trop "magique" ...

J'ai ajouté une preuve de concept à 3cdd4a04c48193cceac6af7db72af06d380014a9

de toute façon, il faudrait un peu de travail, mais je pense que nous pouvons facilement le généraliser pour toutes les interfaces. il n'y a pas de support ici pour Growl, mocha.opts ou d'autres choses liées à process comme les codes de sortie. Nous devrions extraire du code de bin/_mocha et le réutiliser ici. Ensuite, nous pourrions également avoir un argumentaire. Par exemple:

$ node test/my-test.js --reporter=dot

Si quelqu'un a des suggestions, faites-moi savoir

Je pense qu'extraire certains des éléments de bin/_mocha dans une sorte de CLI serait assez judicieux malgré tout.

Je ne suis toujours pas sûr que ce soit vraiment un ajout utile?

Y a-t-il une grande différence pratique entre les éléments suivants?

node test/test.js
./node_modules/.bin/mocha test/test.js
PATH=./node_modules/.bin:$PATH mocha test/test.js
npm test -- test/test.js

J'ai le sentiment que les gens qui n'utilisent pas moka parce qu'ils ne peuvent pas exécuter des fichiers de test via node sont simplement des gens qui n'aiment pas le moka et qui cherchent une excuse! Le moka ne doit pas être pour tout le monde: sourire:

Pareil ici. J'utilise jspm et je ne peux pas import Mocha dans mes tests qui s'exécutent sur le navigateur.

import { describe, before, it } from 'mocha';

Ne peut pas être utilisé dans les navigateurs.

@glenjamin, ça doit juste arriver. Mocha doit avoir une API programmatique de base. Un bon effet secondaire de cela est les tests de nœuds. L'environnement dans lequel il s'exécute consommera l'API programmatique, qu'il s'agisse d'un navigateur, d'une CLI ou de tout autre chose. Mocha.app, quelqu'un? :)

Intéressé par cette fonctionnalité!

+1 pour:
import { describe, before, it } from 'mocha';

Nous avons actuellement const {describe, it} = require('mocha') , mais ce n'est pas nécessaire car les globaux existent déjà.

Si nous sommes concernés par la prise en charge du navigateur, nous pourrions toujours faire const {describe, it} = window.mocha . Nous devons déjà faire cela pour le chai .

eh bien, const {describe, it} = window aussi, je suppose.

c'est si fondamental dans l'architecture de mocha que mocha exporte l'objet global lorsqu'il est groupé.

Je ne pense pas que mocha devrait définir un global autre qu'un seul espace de noms, et peut-être uniquement pour les navigateurs.

l'exécutable mocha continuera à utiliser les globaux; cela ne changera probablement jamais.

ce que nous pouvons (et devrions) viser, c'est la possibilité d'exécuter facilement des tests moka via node sans polluer l'espace de noms global. c'est le sujet de ce problème.

Malheureusement, c'est une boule de ficelle de la taille du Texas que personne n'a eu le temps ni l'énergie de démêler, ce qui devrait être apparent à l'âge de ce problème ...

l'exécutable mocha continuera à utiliser les globaux; cela ne changera probablement jamais.

Bien que je ne sache rien sur la structure du moka, je peux affirmer que ce choix de conception unique est la source du problème.

probablement oui!

J'ai en fait jeté un second regard sur le code, compris (plus ou moins) ce que j'avais fait de mal la dernière fois que j'avais essayé de pirater des globals, pensé à ce qu'il faudrait pour que les fichiers de test soient exécutables avec node test/someFile.js , et je crois savoir comment faire les deux - avec la mise en garde que le faire sans tripler le nombre de cas de bord nécessitera probablement de casser certains cas de bord existants. Plus en détail, mes réflexions sur le design sont:

• éviter les globaux
  
  
  
  • Même dans un demi-majeur, nous ne pouvons pas briser l'écrasante majorité de l'utilisation du moka qui utilise les globaux. L'équipe pourrait tous quitter leur travail quotidien, ne plus jamais dormir, y passer le reste de leur carrière et ne pas avoir littéralement suffisamment d'heures de travail pour gérer le flot inimaginable de demandes d'assistance que cela entraînerait. Par conséquent: ce sera derrière un drapeau, pour toujours .
  
  
  • Actuellement, les interfaces BDD et TDD ont une casse spéciale: les deux seront exportées (et aucune autre interface) en tant que require("mocha").it et al. (Remarque: la raison pour laquelle cela ne casse pas lorsque d'autres interfaces sont sélectionnées peut être que Mocha a un bogue où, dans la plupart des cas, il installera l'interface BDD même si une autre est sélectionnée. # 2207) Je veux m'éloigner de cela.
  
  
  • Les interfaces personnalisées (tierces) doivent pouvoir fonctionner avec le schéma d'exportation (tant qu'elles utilisent l'objet de contexte émis au lieu de coder en dur global ).
  
  
  • Nous ne pouvons pas avoir toutes les interfaces possibles ajoutant ses fonctions à Mocha (ce que require("mocha") exporte).
  
  
  • Si jamais nous corrigeons le bogue où l'interface BDD est toujours configurée, il sera difficile de continuer à exporter également les interfaces BDD et TDD sur Mocha une autre interface est choisie.
  
  
  • Vous ne devriez pas configurer l'interface utilisateur de Mocha sur TDD et utiliser l'interface BDD ou vice versa de toute façon, à moins que vous ne fassiez peut-être require("mocha/tddInterface").test ou require("mocha/interface/bdd").it (à ne pas confondre avec "mocha/lib/interfaces/<interface name>" où les implémentations en direct).
  
  
  • Nous pourrions peut-être conserver le comportement export-BDD-and-TDD-on-Mocha-if-possible pour une compatibilité ascendante jusqu'à un demi-majeur. Je ne m'attends pas à ce que beaucoup de gens se plaignent lorsque nous l'abandonnons, étant donné que les personnes qui l'ont demandé et qui l'utilisent en savent plus que la plupart sur ce qu'ils font et n'en sont pas entièrement satisfaits de toute façon (puisque le globales sont toujours là).
  
  
• capacité de nœud, c'est-à-dire pouvoir exécuter node test/someFile.js au lieu de mocha test/someFile.js
  
  
  
  • Bien que ce soit moins omniprésent que les globaux, je ne pense pas que nous puissions nous permettre de casser les gens qui utilisent var Mocha = require("mocha"); var mocha = new Mocha() etc. (c'est-à-dire l '"interface programmatique"). Nous devions soit détecter cela et éviter d'exécuter Mocha «à la manière des nœuds» ou bien (plus facile pour nous, mais nécessite l'adhésion des utilisateurs) exiger que la capacité des nœuds soit accessible via une importation différente, par exemple require("mocha/nodeable").it ( .describe etc.). Une importation spéciale au lieu de superposer sur require("mocha") serait plus facile à implémenter en toute sécurité et correspondrait à mon désir (décrit et justifié dans la section à éviter les globaux) de s'éloigner de l'exportation d'interfaces sur l'objet Mocha exporté par require("mocha") .
  
  
  • Pour pouvoir node test/someFile.js , il ne suffit pas que someFile.js puisse importer l'interface de Mocha: Mocha doit être instancié, et une fois les tests configurés, Mocha doit s'exécuter. En d'autres termes, require("mocha/nodeable") doit instancier Mocha en plus d'exporter l'interface, puis ... après l'exécution du fichier de test, il doit exécuter Mocha.
  
  
  • Une façon de faire cela serait d'exécuter Mocha dans process.on("beforeExit" , à condition que le fichier de test ne lance aucune action asynchrone.
  
  
  • Une autre façon de faire cela serait d'exécuter Mocha dans process.nextTick ou setImmediate ou setTimeout(..., 0 /* or some small number */) .
  
  
  • Les tests qui configurent leurs trucs avec --delay et exécutés de manière asynchrone avec run() seraient un problème. Pas pour savoir quand courir - c'est plus facile, il y a run() - et même pas pour savoir s'il faut --delay (voir ci-dessous, ou fournir require("mocha/nodeable/delayed") ), mais plutôt parce que run() n'est censé être appelé que dans un seul fichier de test tel qu'il est actuellement conçu. On peut soutenir que la conception est déjà difficile à travailler et que nous aurions besoin de la corriger pour que run() soit de toute façon appelé dans chaque fichier de test, auquel cas son utilisation avec des tests "compatibles avec les nœuds" serait facile après le réparer. Sinon ... je ne sais pas trop quoi faire.
  
  
  • Si nous voulons être en mesure d'autoriser l'appel de ces fichiers de test via mocha au lieu de node (c'est-à-dire que l'utilisation de ceci ne force pas l'utilisation de node ), alors ce qui est require d doit détecter quand la CLI est en cours d'utilisation et ne pas instancier Mocha alors. Ce serait plus facile que de détecter quand l'API programmatique est en cours d'utilisation - la CLI peut définir un état global que ces modules vérifieraient, ou ces modules peuvent vérifier si la CLI est le fichier exécuté par Node.
  
  
  • Nous aurions besoin de rendre les pièces CLI plus modulaires si nous voulions prendre en charge le passage des indicateurs Mocha lors de l'exécution via Node, ou en utilisant mocha.opts , ou tout ce qui permettrait aux fichiers de test compatibles avec les nœuds d'utiliser un comportement autre que celui par défaut de Mocha comportement.
  
  
• En combinant les contraintes de ces deux idées, je propose (et je crois pouvoir mettre en œuvre) :
  
  
  
  • éviter les globaux
  
  
  • Au lieu de passer aux interfaces l'objet global lequel placer leurs fonctions, il leur passera un "objet d'interface sélectionné". (MODIFIE POUR AJOUTER: cela doit être fait à la fois dans lib/mocha.js et browser-entry.js . Autant que je sache, toutes les parties liées au global de la proposition sont réalisables à la fois dans Node et dans le navigateur. )
  
  
  • Ensuite, il copiera tout le contenu de l'objet d'interface sélectionné dans global .
  
  
  • Une option localInterface ( --local-interface sur la CLI) empêchera Mocha de copier depuis l'objet d'interface sélectionné vers global .
  
  
  • DEBATABLE: Initialement, pour la rétrocompatibilité avec require("mocha").it Mocha copiera également les fonctions TDD / BDD de l'objet d'interface sélectionné vers Mocha , mais cela sera obsolète / supprimé plus tard.
    
    
    
    
    
    • (REMARQUE: si nous arrêtons la configuration de BDD lorsqu'il n'est pas sélectionné, nous devrons peut-être effectuer une manipulation encore plus spéciale ici pour configurer le BDD sur un objet d'interface sélectionné factice à partir duquel ceux-ci peuvent être copiés - un bon cas pour supprimer le comportement dans son ensemble, il devient de plus en plus complexe à mesure que nous corrigeons / améliorons d'autres choses tout en essayant de le supporter.)
    
    
    
  
  
  • require("mocha/interface") exportera l'objet d'interface sélectionné.
  
  
  • require("mocha/interface/<specific interface>") appellera l'interface spécifiée avec un nouvel objet d'interface sélectionné qu'elle exportera par la suite.
  
  
  • MODIFIÉ POUR AJOUTER: require("mocha/interface") sera également une propriété sur l'objet mocha dans le navigateur, mocha.interface , pour prendre en charge l'utilisation du navigateur sans système de module.
  
  
  • capacité de nœud
  
  
  • require("mocha/nodeable/<specific interface>") instanciera Mocha, configurera Mocha pour qu'il s'exécute après le fichier de test (vraisemblablement en utilisant setTimeout sauf si delay est utilisé, voir ci-dessus re. delay ) et exporter un objet d'interface sélectionné pour cette interface comme require("mocha/interface/<specific interface>")
  
  
  • Si les options CLI ou mocha.opts sont prises en charge, require("mocha/nodeable") instancier Mocha, configurer Mocha pour qu'il s'exécute après le fichier de test (voir ci-dessus) et effectuer les mêmes étapes de configuration d'interface que la CLI, en exportant le objet d'interface sélectionné comme require("mocha/interface") .
  
  
  • Si nous voulons que les fichiers de test capables de nœuds soient également mocha -able, alors mocha/nodeable & mocha/nodeable/<specific interface> n'est pas nécessaire, nous pouvons récupérer la capacité de nœud sur mocha/interface et mocha/interface/<specific interface> .
  
  

Pensées?

En fait, après réflexion, je propose de fermer ce ticket, sur la justification suivante contre l'utilisation de node <test file> à la place de mocha <test file> :

• Je ne connais aucun avantage qu'il offre.
  
  
  
  • Une idée possible est qu'il n'exécute qu'un seul fichier de test, quels que soient les globes dans mocha.opts . Solution simple: mettez les globs dans le script test dans package.json place: npm test les exécutera tous et mocha ( node_modules/.bin/mocha , npx mocha ) n'exécutera que le ou les fichiers de test spécifiés. (Les fichiers ou globs qui doivent s'exécuter pour tout test, quel que soit le nombre de fichiers de test exécutés, doivent toujours être placés dans mocha.opts .)
  
  
  • Une autre idée possible est qu'il permet de contourner complètement mocha.opts . Cela devrait être réalisable maintenant en utilisant mocha --opts /dev/null (ou sous Windows mocha --opts nul ). Si pour une raison quelconque ce n'est pas le cas, il serait plus simple d'implémenter un indicateur CLI pour ignorer le traitement mocha.opts .
  
  
• Il peut être implémenté en dehors de Mocha; au lieu de "mocha/nodeable" , mettez simplement le même code en utilisant l'API programmatique de Mocha dans un package hypothétique "nodeable-mocha" .
  
  
  
  • Je ne dis pas que ce serait facile à mettre en œuvre en premier lieu, je dis que je ne suis au courant d'aucune façon que cela pourrait être plus difficile à mettre en œuvre en raison de l'extérieur de Mocha.
  
  

Si nous découvrons un avantage significatif qui est plus facile à obtenir dans le noyau qu'en dehors, nous pouvons toujours rouvrir.

Cependant, je propose également de rouvrir le ticket évitant les globaux, car:

• Bien que les avantages ne soient probablement pas pertinents (combien d'autres bibliothèques utilisent des globaux nommés describe , it etc.?), Ils sont possibles en principe (la réponse à cette question pourrait être plus grande que 0, même s'il y en a peu) - ne pas jeter des éléments dans l'espace de noms global est, en théorie, la bonne chose à faire.
  
  
  
  • De plus, mon plan étendrait le même comportement aux interfaces tierces qui sont correctement écrites pour utiliser l'objet "context" émis (pour lequel Mocha utilise actuellement toujours l'objet global) plutôt que de coder en dur l'objet global; alors que nos propres interfaces semblent peu susceptibles d'interférer avec d'autres bibliothèques, nous ne pouvons pas donner de garanties sur les autres interfaces, donc nous leur faciliterions également la tâche.
  
  
• Mon plan nettoierait beaucoup de cas de bord liés dans le comportement actuel (par exemple, en l'étendant à des interfaces tierces, mais aussi en cohérence dans Mocha au lieu de caser spécialement les interfaces BDD et TDD).
• Le seul moyen simple de l'implémenter en dehors de Mocha est d'utiliser l'API programmatique de Mocha et de le patcher de manière singulière , ce qui laisserait également certaines des incohérences et des cas extrêmes mentionnés ci-dessus.

donc vous suggérez plutôt que Mocha fournit un moyen d'exécuter des tests avec mocha mais derrière un drapeau qui ne polluera pas global ?

Une partie de ce qui rend le moka moka et une partie de son succès est qu'il ne nécessite pas de passe-partout pour importer des choses. malgré le dogme autour de la pollution de l'espace de noms global, il existe des raisons tout à fait valables de le faire pour l'ergonomie des développeurs.

alors vous suggérez plutôt que Mocha fournit un moyen d'exécuter des tests avec moka mais derrière un drapeau qui ne polluera pas le monde?

Ouaip.

Une partie de ce qui rend le moka moka et une partie de son succès est qu'il ne nécessite pas de passe-partout pour importer des choses. malgré le dogme autour de la pollution de l'espace de noms global, il existe des raisons tout à fait valables de le faire pour l'ergonomie des développeurs.

Je ne dis pas que je ne suis pas d'accord en général, mais en tant que fonctionnalité opt-in , je peux voir où certains développeurs peuvent vouloir des importations au lieu de globals (peut-être veulent-ils que leur module nomme une variable locale context sans se référer accidentellement au global s'ils oublient var , ils aimeraient peut-être utiliser une interface tierce où ce genre de collision est encore plus probable), et maintenant que j'ai compris comment le faire correctement, c'est aussi plus facile à faire dans Mocha qu'en tant que module complémentaire (en fait, si je ne suis pas aspiré par autre chose, je vais probablement jeter un brouillon dans une branche cette semaine pour le démontrer).

(De plus, nous maintenons déjà une tentative en quelque sorte, où une fois l'interface configurée sur global, elle est copiée sur l'objet Mocha afin que vous puissiez require("mocha").it , mais la version est déjà le maintien est franchement étrange, incohérent , sujet aux bogues et n'évite même pas de polluer l'espace de noms global. Si nous voulons conserver ce type de fonctionnalité, nous pouvons aussi bien le corriger que maintenir une version douteuse.

Ceci est IMO contrairement à la possibilité de node <test file> pour les tests Mocha, qui, à ma connaissance, n'ont aucun avantage et seraient tout aussi difficiles à implémenter à l'intérieur ou à l'extérieur de Mocha.

@stevenvachon
comment se fait-il que const {describe, it} = require('mocha') ne fonctionne pas pour moi? Je viens de ne pas être défini ...

$ node -v
v8.4.0

@zapphyre vous devez toujours exécuter la suite de tests via le programme mocha , et non via node .

Vous ne pouvez pas exécuter plusieurs fichiers sources avec node , vous êtes donc bloqué avec mocha . Je ne connais pas de lanceur / framework de test qui n'a pas son propre exécutable.

Le titre du problème a été mis à jour pour être plus précis

Une autre raison à cela: je voudrais exécuter des tests en utilisant un autre runtime JS, par exemple low.js (car c'est l'une de nos plates-formes, les autres sont node.js, browser - et React Native). Je peux le faire lorsque j'ai un fichier JS qui importe du moka et exécute les tests, je ne peux pas le faire lorsque je dois appeler mocha pour exécuter des tests.

Je veux dire, vous le faites déjà pour le navigateur. Sur cette plate-forme, j'ai du code JS qui importe "mocha" puis exécute les tests à partir d'un objet global mocha utilisant mocha.run() .

Dans le navigateur, je

• Chargez moka et obtenez un objet global mocha
• Exécutez mocha.setup({ui: 'bdd'});
• Chargez tous les fichiers de test à l'aide de SystemJS
• Puis je cours

      mocha.checkLeaks();
      mocha.globals([]);
      mocha.run();

Et c'est tout. Lorsque j'essaye la même chose dans node.js, en utilisant une instruction require au lieu de SystemJS pour charger un fichier de test, j'obtiens (en utilisant mocha 5.2.0)

> mocha.run();
TypeError: Cannot read property 'search' of undefined
    at Mocha.mocha.run (/home/mha/one/node_modules/mocha/mocha.js:149:54)

EDIT: J'ai essayé https://github.com/mochajs/mocha/wiki/Using-Mocha-programmatically et mocha.addFile au lieu de simplement le charger, même résultat.

Existe-t-il actuellement un moyen d'importer le / la description?

Il y a une nouvelle page Wiki (datant de 20 heures) https://github.com/mochajs/mocha/wiki/Using-mocha-programmatically mais c'est pour exécuter les tests.

Une autre raison à cela: je voudrais exécuter des tests en utilisant un autre runtime JS, par exemple low.js (car c'est l'une de nos plates-formes, les autres sont node.js, browser - et React Native). Je peux le faire lorsque j'ai un fichier JS qui importe du moka et exécute les tests, je ne peux pas le faire lorsque je dois appeler mocha pour exécuter des tests.

Si le runtime alternatif a un exécutable de type nœud (ce que je pense que low.js fait?), Vous pouvez faire alternative-executable ./node_modules/.bin/_mocha , et cela devrait fonctionner

Je ne connais pas de lanceur / framework de test qui n'a pas son propre exécutable.

https://github.com/tapjs/node-tap/#tutti -i-gusti-sono-gusti

Maintenant que https://github.com/mochajs/mocha/issues/3006 est résolu, il serait bien d'avoir les mêmes exportations nommées dans le navigateur.

Actuellement, ce qui suit fonctionne:

<script type="module">
  import './node_modules/mocha/mocha.js'
  console.log(mocha)
</script>

Mais ce qui suit n'est pas:

<script type="module">
  import { mocha } from './node_modules/mocha/mocha.js'
  console.log(mocha)
</script>

(comme demandé par https://github.com/mochajs/mocha/issues/956#issuecomment-167453800)

Cela pourrait devenir plus facile lorsque nous fusionnons notre branche avec roll-up et que nous installons des transpileurs. Il semble possible d'avoir un bundle esm et un bundle hérité qui consomme les chemins de code esm et ajoute les fuites globales. Nous devrions prendre beaucoup de soin de ne modifier que les chemins de code et les bundles nouvellement ajoutés afin de ne pas casser ou coder à la fois dans les navigateurs et dans les nœuds

Avec les variables globales et les typages, cela fait juste un héritage moka.

Btw vient de créer @types/mocha sans globaux: https://github.com/whitecolor/mocha-types

J'espère qu'ils (globaux) seront bientôt supprimés officiellement.