Jest: Prise en charge de RequireJS

++

Il est sur notre feuille de route de prendre en charge les modules complémentaires du système de modules pour Jest (comme les modules require.js, es6, etc.), mais malheureusement, nous n'en sommes pas encore là.

Laissons ce problème ouvert pour suivre les progrès à ce sujet, cependant - je pense qu'il serait assez utile de prendre en charge les chargeurs require.js

@jeffmo webpack prend en charge commonjs/es6/amd. Si nous pouvions intégrer Jest en tant que plugin, nous pourrions probablement obtenir tout cela gratuitement.

++

nous avons de nombreux projets dans une grande organisation et prévoyons d'utiliser jest mais nous sommes 100% requirejs. Une eta sur l'intégration de requirejs ?

++

J'aimerais aussi essayer Jest, mais le projet actuel sur lequel je travaille utilise RequireJS.

:+1:

Quelqu'un a suggéré de l'utiliser comme cale, est-ce que quelqu'un l'a essayé ?

https://github.com/Jakobo/redefine

_Faisable avec mises en garde_. J'ai implémenté une petite version avec nodefy dans un aléatoire qui pourrait faire l'affaire comme palliatif . Voir scripts.cjs sous packages .

Test décisif : vos alias de module AMD s'alignent sur le module correspondant sous node_modules . Si le test décisif échoue, mais que vous êtes désespéré, vous pouvez nouer des modules AMD purs et/ou ajouter des liens symboliques à node_modules, mais l'idée me rend triste. De mon point de vue, les externes que j'utilise ont tendance à implémenter UMD et à installer par npm sur des noms alignés avec mes alias AMD - ce n'est pas grave.

(J'ai vérifié uRequire avant nodefy, mais le modèle CommonJS le rend fonctionnellement équivalent à nodefy - je vais prendre l'outil ciblé. J'ai également vérifié amdefine, mais jest utilise la correspondance regex sur 'require' - il y a peut-être un AMD anonyme Il y a toujours UMD, mais coder UMD avec des références document éparses ressemble à de mauvaises manières.)

+1

++

Nous utilisons react, backbone et requirejs dans tout notre nouveau code côté client. J'aimerais pouvoir utiliser la plaisanterie et soulager une partie de la douleur des tests de réaction. Ce serait bien de ramener les choses au niveau de l'unité. Actuellement, nos tests pour le code de réaction sont effectués avec rspec et un pilote Web. Bien que cela fonctionne, il est loin d'être idéal pour des raisons évidentes.

Existe-t-il encore une solution de contournement pratique? Le principal problème que je rencontre est les instructions de définition qui enveloppent les composants de réaction.

+1

@petehunt m'a activé Webpack, c'est donc quelque chose à considérer également.

+1

Quelqu'un peut-il m'indiquer un exemple de jasmine/webpack ou jest/webpack exécutant des tests de navigateur avec une couverture de code ?

++

Quand pouvons-nous nous attendre à un support pour requirejs ?

+1

+1

+1

+1

+1

+1

Si vous utilisez module.exports au lieu de return pour votre appel de définition, vous pouvez l'ajouter à votre préprocesseur.

Fonctionne pour moi :pouce:

// preprocessor.js
var ReactTools = require('react-tools');
module.exports = {
  process: function(src) {
    if (/define\(.*?\{/.test(src)) {
      //Remove AMD ceremony for use without require.js or almond.js
      src = src.replace(/define\(.*?\{/, '')
        .replace(/(}\);|}\))$/,'');
    }

    return ReactTools.transform(src);
  }
};

++

+1

+1

+1 pour la prise en charge de RequireJS

+1

@charliedowler Pourriez-vous illustrer un peu plus cette approche. Je suis en train de l'essayer et je rencontre quelques problèmes. j'ai commencé par ajouter

if (typeof(module) == 'object' && module.exports) { module.exports = <my_element>;  }

Pourtant, j'utilise return , donc j'obtiens une erreur d'analyseur du préprocesseur. Je pensais pouvoir m'en sortir en étendant le RegEx pour qu'il corresponde également au dernier retour. Mais ça n'a pas l'air de fonctionner du tout. Je reçois toujours l'erreur "déclaration de retour illégale". Probablement quelque chose ne va pas avec l'expression, et il ne l'attrape pas.

if (/define\(.*?\{/.test(src)) {
  src = src.replace(/(define\(.*?\{|return.*[\s]}\);?$)/g,'');  
}

Existe-t-il un moyen pour moi d'écrire src sur stdout ? Un simple console.log ne fonctionne pas.

Et enfin, en supposant que tout cela fonctionne. Comment gérez-vous les dépendances ? Comme par exemple React ?

+1

Ah ! J'avais joué avec (et j'appréciais beaucoup les blagues). J'ai essayé de l'intégrer dans un projet réel aujourd'hui et j'ai découvert qu'il n'y avait pas de support requireJS :sob: ... briseur d'affaire pour tous les projets "réels" actuels. Triste en effet. C'était sûrement une idée excitante!

:+1:

+1

+1

:+1:

:pouces vers le haut:

:+1:

:+1:

J'ai donc résolu ce problème en utilisant webpack pour compiler mes modules et tests AMD ensemble. Cela m'a permis d'utiliser également toutes sortes de chargeurs supplémentaires avec mes tests. https://github.com/ninjapanzer/Backbone-Flux-React-Webpack

:+1:

+1

+1

+1

Merci d'avoir signalé ce problème et merci de votre patience. Nous avons informé l'équipe principale d'une mise à jour sur ce problème. Nous attendons une réponse dans les 30 prochains jours ou le problème pourrait être résolu.

+1

@facebook-github-bot-4 s'il vous plaît, faites-le !

+1

+1

++

J'ai travaillé sur Jestpack qui remplace le "HasteModuleLoader" de Jest pour prendre en charge Webpack. En conséquence, cela signifie que vous pouvez utiliser n'importe quel système de module pris en charge par Webpack, y compris AMD.

En passant, est-ce que quelqu'un connaît de grands projets open source utilisant Jest autres que ceux utilisant des modules de hâte de style FB, car cela serait vraiment utile pour tester les performances de Jestpack?

J'ai également travaillé sur jest-requirejs qui est plus une tentative de préprocesseur de plaisanterie standard qui analyse le fichier de configuration du projet main.js puis exécute un deamdify , qui supprime le define wrapper, réécrit les chemins requis en fonction des détails de la baseUrl et des chemins spécifiés par main.js, puis transmet le fichier transformé à jest comme d'habitude.

Je travaille toujours sur la syntaxe des plugins/chargeurs et réécrit les chemins jest.dontMock("") , jest.setMock("") et require.requireActual("") dans l'environnement de test.

Hé les gars c'est vraiment génial. J'aime l'idée de Jestpack et j'ai eu l'intention de rendre beaucoup plus facile la prise en charge de résolveurs de modules supplémentaires. Enfin, je souhaite également réorganiser le site Web et recommander des solutions comme Jestpack dans le cadre du guide de démarrage (que j'ai en tête :) ). @richardscarrott et @sterpe s'il vous plaît laissez-moi savoir si vous avez besoin de quelque chose.

Aussi cc @mwolson et @ColCh

(A tous les autres : s'il vous plaît arrêtez de voter pour les commentaires, cela n'est pas utile. Si vous voulez quelque chose de construit pour la plaisanterie, veuillez envoyer une demande d'extraction. Le code gagne les arguments ! Personnellement, je ne peux pas prioriser les fonctionnalités uniquement parce que les membres de la communauté en ont besoin et je n'utilisez pas _tous les chargeurs de modules_ qui existent moi-même.).

Jestpack est intéressant, même si je ne suis pas fan de devoir créer un point d'entrée par test. https://github.com/Ticketmaster/jest-webpack-alias résout le problème de manière un peu plus générique, au prix d'un certain prétraitement et d'éventuels bogues non encore découverts dus à la réimplémentation du code de résolution du module de webpack.

Aussi : les guides de démarrage devraient probablement mentionner qu'il est judicieux de limiter les fichiers sur lesquels votre préprocesseur s'exécute, si vous en avez un, sinon cela ralentit considérablement les tests.

les préprocesseurs ne sont exécutés qu'une seule fois et vous pouvez fournir une fonction de clé de cache. jest ne relancera pas votre préprocesseur si un fichier n'a pas changé.

C'est peut-être le cas, mais même la première exécution a suffi à ajouter environ 10 secondes à l'exécution de notre suite de tests.

D'accord que ce n'est pas rapide. Chez FB, la première exécution prend presque deux fois plus de temps que les exécutions suivantes, mais personnellement, je n'en vois pas d'autre pour résoudre ce problème – nous utilisons babel et d'autres transformations personnalisées chez FB ; nous ne pouvons pas exécuter de tests sans préprocesseur :)

La mise en cache du préprocesseur me mordait lors du développement du préprocesseur requirejs. J'utilise encore la plupart du temps [email protected] qui n'avait pas de cache je crois?

Cela devrait fonctionner correctement avec 0,5 !

Webpack est très rapide en mode dev-watch.

Parce que:

1. Webpack garde leur runtime en mémoire (sans rechargement)
2. Le code source compilé se trouve également en mémoire.

Ainsi, dans mon préprocesseur Jest, j'ai implémenté seulement (2) points.

En bref , un package ( mémoire FS et d'exécuter les cas de test dans la mémoire FS .

C'est mon point de vue...

Mais nous avons un autre problème maintenant : il n'est pas possible d'injecter de la mémoire FS dans Jest pour le moment.

J'ai pensé à utiliser l'API de cache Jest privée - pour injecter la source compilée directement dans le cache. C'est peut-être un hack, donc je me suis trompé ici : jest-webpack/issues/4#issuecomment-98623189

Ah, je dois mentionner que Karma avec Webpack comme préprocesseur fonctionne également très lentement. Donc, je pense que la principale baisse des performances est due aux rechargements d'exécution de webpack entre les fichiers.

@cpojer J'ai pensé que c'était votre intention de rendre les chargeurs de modules configurables car ils étaient déjà en option, alors j'ai pensé essayer avec Jestpack. Le seul vrai problème que j'ai rencontré était de comprendre la logique pour découvrir des maquettes manuelles pour node_modules https://github.com/facebook/jest/issues/509 , j'ai fini par choisir une solution qui avait du sens pour moi mais si vous ' Si vous êtes en mesure de fournir des informations sur ce problème, il serait bon d'aligner le chargeur de module de Jestpack avec le HasteModuleLoader.

@mwolson La raison pour laquelle Jestpack utilise un point d'entrée séparé par fichier de test est de s'assurer qu'il peut toujours tirer parti des multi-processus de Jest.

moduleLoader peut déjà être spécifié dans le cadre de la configuration, en fait.

++

On aimerait ça aussi. Jest semble être un logiciel génial, mais ne peut pas réécrire tout ce que nous avons pour ne pas prendre en charge RequireJS.

+1

Est-ce que quelqu'un de la communauté est intéressé à travailler là-dessus? Je serais heureux de soutenir les gens à travers cela et de créer un plugin Jest officiel. Il est peu probable que nous investissions massivement dans ce domaine chez FB de si tôt. L'équipe Jest est très petite (1,5 personne) et nous ne pouvons malheureusement pas travailler sur toutes ces fonctionnalités.

Sur la base de l'état actuel de la communauté JavaScript et de la norme, il ne semble pas que require js lui-même ait un avenir énorme pour la création de code JavaScript. Nous avons maintenant un système de module standardisé dans ES2015. Babel et Jest sont maintenant pleinement intégrés et travaillent bien ensemble. Je recommanderai à quiconque de passer aux modules CommonJS ou ES2015, ce qui mettra à votre disposition davantage d'outils prêts à l'emploi.

require JS a également un document ici sur la façon de convertir CommonJS en require.js qui peut être utilisé pour les déploiements de production, voir : http://requirejs.org/docs/commonjs.html

Personnellement, je ne vois aucun avantage à écrire du code en utilisant require JS. Je serais également heureux d'aider à écrire un codemod qui peut aider à transformer les bases de code JS requises en CommonJS. Un autre défi pourrait être d'écrire un plugin babel requireJS vers CommonJS et de l'insérer dans le préprocesseur de Jest.

@cpojer J'ai quelque peu réussi avec l'approche du préprocesseur ici https://github.com/sterpe/jest-requirejs/blob/master/index.js, mais j'ai seulement implémenté une transformation pour les plugins !text/ jusqu'à présent. Notre équipe s'est complètement éloignée de requirejs, je n'ai donc pas eu de raison de continuer dans cette voie.

Je suis d'accord, je vois peu d'intérêt à utiliser RequireJS pour la création de code. Il me semble logique de compiler le code du module CommonJS/ES2015 sur requirejs pour la production, mais cela ne semble pas génial d'écrire du code avec ce style manuellement.

Je viens de faire la migration de RequireJS vers webpack. Il y a plus de 300 composants dans notre base de code. L'ensemble du processus était étonnamment facile et indolore.

L'outil que j'ai utilisé était https://github.com/Skookum/recast-to-cjs pour convertir le code d'AMD en style CommonJS.

Également avec l'aide de https://github.com/facebook/jscodeshift , nous avons migré notre base de code de React 0.11 à 0.14 en quelques jours.

J'espère que cela pourra aider quelqu'un dans la même situation.

@tendant sympa ! C'est exactement ce dont je parlais avant :) Heureux que cela ait si bien fonctionné pour vous.

Voici mon travail autour de :
https://github.com/1twitif/testRequireJSAmdModulesWithJest
Cela fonctionne au moins pour ce cas d'utilisation :
http://stackoverflow.com/questions/33889662/not-able-to-load-amd-modules-through-jest

Puisque ceci est fermé, cela signifie-t-il que Facebook ne va pas ajouter de support pour cela ?

Si par Facebook vous entendez moi, alors oui, il est peu probable qu'il y ait un support "officiel". Cela ne devrait pas vous empêcher de contribuer à Jest et d'obtenir cette fonctionnalité, mais je pense que la plupart des gens sont passés aux modules ES ou à CommonJS ces jours-ci.

Ouais je sais. Malheureusement, je ne peux pas m'éloigner de ces dépendances car c'est pour le travail.

babel-plugin-transform-amd-to-commonjs peut s'avérer utile pour résoudre le problème de Jest+AMD, en particulier si vous utilisez déjà quelque chose comme babel-jest.

J'ai mis en place un exemple de projet qui montre comment vous pouvez faire en sorte que Jest exige de manière transparente des fichiers AMD en exécutant la transformation dans l'environnement de test.

Je ne suis pas sûr des détails d'une telle approche dans un projet réel - en particulier une bonne approche pour le partage de configuration entre Jest/RequireJS/Webpack/etc. La prise en charge de Jest pour le fichier de configuration .js serait une étape vers une solution plus réutilisable (voir https://github.com/facebook/jest/issues/2140).

@msrose c'est génial. Merci beaucoup d'avoir partagé ceci.

Je comprends que c'est un vieux problème. Une simple transformation pourrait fonctionner :

exports.process = function (content) {
  return 'function define(name, deps, body) { module.exports = body.apply(undefined, deps.map(require)); }' + content;
}

Je pense que la transformation d'AMD -> CJS peut être effectuée de plusieurs manières, par exemple, deamdify , wrapper injecté, etc. Le problème, toujours non résolu, concerne les syntaxes de chargeur/plugin de style Require. C'est des trucs comme fooTemplate = require('tpl!foo.tpl') et barJson = require('json!bar.json') (comme des trucs relativement courants). Mais il y en avait beaucoup et les projets require-js monde réel sont jonchés de ce genre de syntaxe.

Ce serait formidable s'il y avait un moyen simple de réutiliser directement les plugins require-js existants dans le système de transformation qui alimente finalement le chargeur de modules de jest |.

+1

ReferenceError: define is not defined

+1

ÉCHEC srcApp.test.js
● Échec de l'exécution de la suite de tests

ReferenceError: define is not defined

Vous devez utiliser umd au lieu de amd. Si ce n'est pas faisable, vous devez ajouter une transformation (par exemple le plugin babel lié ci-dessus).

En ce qui concerne la syntaxe loader! , nous ne la prendrons pas en charge (nous ne la prenons pas non plus en charge pour Webpack). La solution de contournement consiste à transformer les importations (en supprimant les chargeurs) et à laisser Jest se transformer en utilisant sa configuration transform . Discussion connexe : #4868