Jest: Unterstützung für RequireJS

++

Es steht auf unserer Roadmap, Modulsystem-Add-Ons für Jest zu unterstützen (wie require.js, es6-Module usw.), aber leider sind wir noch nicht ganz am Ziel.

Lassen wir dieses Problem jedoch offen, um den Fortschritt zu verfolgen – ich denke, es wäre ziemlich nützlich, require.js-Loader zu unterstützen

@jeffmo webpack unterstützt commonjs/es6/amd. Wenn wir Scherz als Plugin einbringen könnten, könnten wir all das Zeug wahrscheinlich kostenlos bekommen.

++

wir haben viele projekte in einer großen organisation und planen, scherz zu verwenden, aber wir sind zu 100% anforderungen. Irgendwelche Eta auf requirejs-Integration?

++

Ich würde auch gerne Witze ausprobieren, aber das aktuelle Projekt, an dem ich arbeite, verwendet RequireJS.

:+1:

Jemand hat vorgeschlagen, dies als Shim zu verwenden, hat es jemand versucht?

https://github.com/Jakobo/redefine

_Machbar mit Vorbehalten_. Ich habe einen kleinen Build mit Nodefy in einem zufälligen Repo implementiert, der als Notlösung ausreichen könnte. Siehe scripts.cjs unter Pakete .

Lackmustest: Ihre AMD-Modul-Aliasnamen stimmen mit dem entsprechenden Modul unter node_modules überein . Wenn der Lackmus-Test fehlschlägt, Sie aber verzweifelt sind, könnten Sie reine AMD-Module nodefifizieren und / oder symbolische Links zu node_modules hinzufügen, aber die Idee macht mich traurig. Aus meiner Sicht neigen die Externals, die ich verwende, dazu, UMD zu implementieren und von npm auf Namen zu installieren, die mit meinen AMD-Aliasnamen übereinstimmen - keine große Sache.

(Ich habe uRequire vor nodefy ausgecheckt, aber die CommonJS-Vorlage macht es funktional äquivalent zu nodefy – ich nehme das Zieltool. Ich habe auch amdefine ausgecheckt, aber jest verwendet Regex-Matching bei 'require' - vielleicht gibt es eine anonyme AMD Winkel? Es gibt immer UMD, aber das Codieren von UMD mit verstreuten document Referenzen klingt nach schlechten Manieren.)

+1

++

Wir verwenden in all unserem neuen clientseitigen Code React, Backbone und Requirejs. Ich würde gerne in der Lage sein, Scherze zu verwenden und einige der Schmerzen beim Testen zu lindern. Es wäre schön, die Dinge auf die Ebene der Einheiten zu bringen. Derzeit werden unsere Tests für den React-Code mit rspec und einem Webtreiber durchgeführt. Dies funktioniert zwar, ist aber aus offensichtlichen Gründen nicht ideal.

Gibt es schon einen praktischen Workaround? Das Hauptproblem, auf das ich stoße, sind die define-Anweisungen, die die Reaktionskomponenten umschließen.

+1

@petehunt Hat mich auf Webpack aufmerksam gemacht, also ist dies auch etwas zu beachten.

+1

Kann mir jemand ein Beispiel für Jasmin/Webpack oder Jest/Webpack zeigen, die Browsertests mit Codeabdeckung ausführen?

++

Wann können wir mit der Unterstützung für requirejs rechnen?

+1

+1

+1

+1

+1

+1

Wenn Sie module.exports anstelle von return für Ihren define-Aufruf verwenden, können Sie dies zu Ihrem Präprozessor hinzufügen.

Funktioniert bei mir :thumbsup:

// 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 für RequireJS-Unterstützung

+1

@charliedowler Würde es Ihnen etwas

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

Da ich jedoch return , erhalte ich einen Parser-Fehler vom Präprozessor. Ich dachte, ich könnte davonkommen, indem ich den RegEx so erweitere, dass er auch mit der letzten Rückkehr übereinstimmt. Aber es scheint überhaupt nicht zu funktionieren. Ich bekomme immer den Fehler "illegal return Statement". Wahrscheinlich stimmt etwas mit dem Ausdruck nicht, und er fängt ihn nicht ein.

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

Gibt es eine Möglichkeit, src auf stdout zu schreiben? Ein einfaches console.log funktioniert nicht.

Und schließlich, vorausgesetzt, ich bekomme das alles zum Laufen. Wie gehen Sie mit Abhängigkeiten um? Wie zum Beispiel Reagieren?

+1

Ah! Ich hatte mit gespielt (und Spaß sehr genossen). Habe heute versucht, es in ein aktuelles Projekt zu integrieren, und habe festgestellt, dass kein Bedarf an JS-Unterstützung besteht :sob: ... Deal Breaker für alle aktuellen "echten" Projekte. Traurig in der Tat. Das war sicher eine spannende Idee!

:+1:

+1

+1

:+1:

:Daumen hoch:

:+1:

:+1:

Also habe ich dies gelöst, indem ich Webpack verwendet habe, um meine AMD-Module und Tests zusammen zu kompilieren. Dadurch konnte ich bei meinen Tests auch alle möglichen Zusatzlader einsetzen. https://github.com/ninjapanzer/Backbone-Flux-React-Webpack

:+1:

+1

+1

+1

Vielen Dank, dass Sie dieses Problem gemeldet haben, und danken Ihnen für Ihre Geduld. Wir haben das Kernteam benachrichtigt, um ein Update zu diesem Problem zu erhalten. Wir suchen innerhalb der nächsten 30 Tage nach einer Antwort oder das Problem kann geschlossen werden.

+1

@facebook-github-bot-4 bitte mach es!

+1

+1

++

Ich habe an Jestpack gearbeitet, das ein Ersatz für Jests 'HasteModuleLoader' ist, um Webpack zu unterstützen. Das bedeutet, dass Sie jedes Modulsystem verwenden können, das Webpack unterstützt, einschließlich AMD.

Nebenbei bemerkt, kennt jemand große (ish) Open-Source-Projekte, die Jest verwenden, außer denen, die Eile-Module im FB-Stil verwenden, da dies wirklich nützlich wäre, um die Leistung von Jestpack zu testen?

Ich habe auch an jest-requirejs was eher ein Versuch eines Standard-Jest-Präprozessors ist, der die Konfigurationsdatei des Projekts main.js analysiert und dann eine deamdify ausführt, die das define Wrapper, schreibt die erforderlichen Pfade basierend auf den Details der angegebenen baseUrl und Pfade von main.js neu und übergibt dann die transformierte Datei wie gewohnt an jest.

Arbeite noch an der Plugin/Loader-Syntax und schreibe jest.dontMock("") , jest.setMock("") und require.requireActual("") Pfade innerhalb der Testumgebung um.

Hey Leute das ist echt toll. Ich mag die Idee von Jestpack und wollte es viel einfacher machen, zusätzliche Modulresolver zu unterstützen. Schließlich möchte ich auch die Website überarbeiten und Lösungen wie Jestpack als Teil des Getting Started Guides empfehlen (den ich im Kopf habe :) ). @richardscarrott und @sterpe bitte lass es mich wissen, wenn du etwas brauchst.

Auch cc @mwolson und @ColCh

(An alle anderen: Bitte hör auf, Kommentare zu positiv zu bewerten, es ist nicht hilfreich. Wenn du etwas zum Spaß bauen möchtest, sende bitte einen Pull-Request. Code gewinnt Argumente! Ich persönlich kann Funktionen nicht priorisieren, nur weil die Leute in der Community sie brauchen und ich benutze nicht _alle Modullader_ die es selbst gibt.).

Jestpack ist interessant, obwohl ich kein Fan davon bin, einen Einstiegspunkt pro Test erstellen zu müssen. https://github.com/Ticketmaster/jest-webpack-alias löst das Problem etwas allgemeiner, auf Kosten einiger Vorverarbeitung und möglicher noch unentdeckter Fehler aufgrund der Neuimplementierung des Modulauflösungscodes von Webpack.

Außerdem: In den Anleitungen für die ersten Schritte sollte wahrscheinlich erwähnt werden, dass es eine gute Idee ist, die Dateien einzuschränken, auf denen Ihr Präprozessor ausgeführt wird, falls Sie einen haben, andernfalls verlangsamt dies die Testläufe erheblich.

Präprozessoren werden nur einmal ausgeführt und Sie können eine Cache-Schlüsselfunktion bereitstellen. Jest führt Ihren Präprozessor nicht erneut aus, wenn sich eine Datei nicht geändert hat.

Das mag sein, aber selbst der erste Durchlauf reichte aus, um die Ausführung unserer Testsuite um etwa 10 Sekunden zu verlängern.

Einverstanden, dass das nicht schnell ist. Bei FB dauert der erste Durchlauf fast doppelt so lange wie nachfolgende Durchläufe, aber ich persönlich sehe keine andere Lösung für dieses Problem – wir verwenden Babel und andere benutzerdefinierte Transformationen bei FB; Wir können keine Tests ohne Präprozessor ausführen :)

Das Präprozessor-Caching hat mich bei der Entwicklung des Requirejs-Präprozessors gebissen. Ich benutze meistens immer noch

Mit 0,5 sollte es klappen!

Webpack ist im Dev-Watch-Modus sehr schnell.

Denn:

1. Webpack behält seine Laufzeit im Speicher (ohne Reloads)
2. Der kompilierte Quellcode befindet sich ebenfalls im Speicher.

Also habe ich in meinem Jest-Präprozessor nur (2) Punkt implementiert.

Kurz gesagt , ein Paket ( Speicher FS und führen Sie Testfälle im Speicher FS aus .

Das ist mein Standpunkt...

Aber wir haben jetzt ein anderes Problem: Es ist momentan nicht möglich, Speicher FS in Jest einzuschleusen .

Ich dachte darüber nach, die private Jest-Cache-API zu verwenden, um die kompilierte Quelle direkt in den Cache zu injizieren. Vielleicht ist es ein Hack, also habe ich mich hier geirrt:

Ah, ich sollte erwähnen, dass Karma mit Webpack als Präprozessor auch sehr langsam arbeitet. Ich denke also, dass der Hauptleistungsabfall auf das Neuladen der Webpack-Laufzeit zwischen Dateien zurückzuführen ist.

@cpojer Ich dachte, es war Ihre Absicht, https://github.com/facebook/jest/issues/509. Am Ende habe ich nur eine Lösung gefunden, die für mich sinnvoll war, aber wenn Sie Um einen Einblick in dieses Thema zu geben, wäre es schön, den Modullader von Jestpack mit dem HasteModuleLoader abzugleichen.

@mwolson Der Grund, warum Jestpack einen separaten Einstiegspunkt pro Testdatei verwendet, besteht darin, sicherzustellen, dass es weiterhin die Multiprozesse von Jest nutzen kann.

moduleLoader kann eigentlich schon als Teil der Konfiguration angegeben werden.

++

Das möchten wir auch. Jest scheint eine großartige Software zu sein, kann aber nicht alles neu schreiben, was wir haben, um keine RequireJS-Unterstützung zu berücksichtigen.

+1

Hat jemand aus der Community Interesse daran mitzuarbeiten? Ich würde mich freuen, Leute dabei zu unterstützen und ein offizielles Jest-Plugin zu erstellen. Es ist unwahrscheinlich, dass wir bei FB in absehbarer Zeit stark in dies investieren werden. Das Jest-Team ist sehr klein (1,5 Personen) und wir können leider nicht an all diesen Funktionen arbeiten.

Basierend auf dem aktuellen Stand der JavaScript-Community und dem Standard scheint es nicht so zu sein, als hätte die Anforderung von js selbst eine große Zukunft für das Erstellen von JavaScript-Code. Wir haben jetzt in ES2015 ein standardisiertes Modulsystem. Babel und Jest sind jetzt vollständig integriert und arbeiten gut zusammen. Ich empfehle jedem, auf CommonJS- oder ES2015-Module umzusteigen, wodurch Ihnen sofort mehr Tools zur Verfügung stehen.

require JS bietet hier auch ein Dokument zum Konvertieren von CommonJS in require.js, das für Produktionsbereitstellungen verwendet werden kann, siehe: http://requirejs.org/docs/commonjs.html

Persönlich sehe ich keinen Vorteil darin, Code mit require JS zu schreiben. Ich würde auch gerne helfen, einen Codemod zu schreiben, der helfen kann, erforderliche JS-Codebasen in CommonJS umzuwandeln. Eine weitere Herausforderung könnte darin bestehen, ein requireJS-to-CommonJS-Babel-Plugin zu schreiben und es in den Präprozessor von Jest zu übernehmen.

@cpojer Ich war mit dem Präprozessor-Ansatz hier https://github.com/sterpe/jest-requirejs/blob/master/index.js einigermaßen erfolgreich, habe aber bisher nur eine Transformation für !text/ -Plugins implementiert. Unser Team hat sich vollständig von requirejs entfernt, sodass ich keinen Grund hatte, diesen Weg fortzusetzen.

Ich stimme zu, ich sehe wenig Wert darin, RequireJS zum Erstellen von Code zu verwenden. Es macht für mich Sinn, CommonJS/ES2015-Modulcode in requirejs für die Produktion zu kompilieren, aber es scheint nicht gut zu sein, Code mit diesem Stil manuell zu schreiben.

Ich habe gerade die Migration von RequireJS zu Webpack durchgeführt. Es gibt mehr als 300 Komponenten in unserer Codebasis. Der ganze Vorgang war überraschend einfach und schmerzlos.

Das Tool, das ich verwendet habe, war https://github.com/Skookum/recast-to-cjs zum Konvertieren von Code vom AMD- in den CommonJS-Stil.

Auch mit Hilfe von https://github.com/facebook/jscodeshift haben wir innerhalb weniger Tage unsere Codebasis von React 0.11 auf 0.14 migriert.

Hoffe das kann jemandem in der gleichen Situation helfen.

@tendant nett! Genau davon habe ich vorher gesprochen :) Schön, dass es bei dir so gut geklappt hat.

Hier ist meine Arbeit rund um:
https://github.com/1twitif/testRequireJSAmdModulesWithJest
Es funktioniert zumindest für diesen Anwendungsfall:
http://stackoverflow.com/questions/33889662/not-able-to-load-amd-modules-through-jest

Bedeutet das, dass Facebook dies nicht unterstützt, da dies geschlossen ist?

Wenn Sie mit Facebook meinen, dann ja, es ist unwahrscheinlich, dass es "offiziellen" Support gibt. Das sollte Sie nicht daran hindern, zu Jest beizutragen und diese Funktion zu nutzen, aber ich glaube, die meisten Leute sind heutzutage zu ES-Modulen oder CommonJS übergegangen.

Ja ich weiß. Leider kann ich mich nicht von diesen Abhängigkeiten entfernen, weil es für die Arbeit ist.

babel-plugin-transform-amd-to-commonjs kann sich als nützlich erweisen, um das Problem von Jest+AMD zu lösen, insbesondere wenn Sie bereits so etwas wie babel-jest verwenden.

Ich habe ein Beispielprojekt eingerichtet, das zeigt, wie Sie Jest transparent AMD-Dateien anfordern können, indem Sie die Transformation in der Testumgebung ausführen.

Ich bin mir der Details eines solchen Ansatzes in einem tatsächlichen Projekt nicht sicher - insbesondere ein guter Ansatz für die gemeinsame Nutzung von Konfigurationen zwischen Jest/RequireJS/Webpack/etc. Jest-Unterstützung für .js-Konfigurationsdateien wäre ein Schritt in Richtung einer wiederverwendbareren Lösung (siehe https://github.com/facebook/jest/issues/2140).

@msrose das ist toll. Vielen Dank, dass Sie dies teilen.

Ich verstehe, dass dies ein altes Problem ist. Eine einfache Transformation könnte funktionieren:

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

Ich denke, die Transformation von AMD -> CJS kann auf verschiedene Weise durchgeführt werden, zB deamdify , injizierter Wrapper usw. Das noch ungelöste Problem sind Loader/Plugin-Syntaxen im Require-Stil. Das sind die Sachen wie fooTemplate = require('tpl!foo.tpl') und barJson = require('json!bar.json') (als relativ gebräuchliche). Aber davon gab es ziemlich viele und reale require-js Projekte sind mit dieser Art von Syntax übersät.

Es wäre großartig, wenn es eine einfache Möglichkeit gäbe, die vorhandenen require-js Plugins direkt im Transformationssystem wiederzuverwenden, das letztendlich in den Modullader von jest | einspeist.

+1

ReferenceError: define is not defined

+1

FAIL srcApp.test.js
● Testsuite konnte nicht ausgeführt werden

ReferenceError: define is not defined

Sie sollten umd anstelle von amd verwenden. Wenn das nicht möglich ist, sollten Sie eine Transformation hinzufügen (zB das oben verlinkte Babel-Plugin).

Wenn es um die loader! Syntax geht, werden wir diese nicht unterstützen (wir unterstützen sie auch nicht für Webpack). Abhilfe besteht darin, die Importe zu transformieren (die Loader zu entfernen) und Jest mit seiner transform Konfiguration transformieren zu lassen. Zugehörige Diskussion: #4868