Jest: Soporte para RequireJS

++

Está en nuestra hoja de ruta admitir complementos del sistema de módulos para Jest (como require.js, módulos es6, etc.), pero lamentablemente aún no hemos llegado a ese punto.

Sin embargo, dejemos este problema abierto para realizar un seguimiento del progreso. Creo que sería bastante útil admitir cargadores require.js.

El paquete web de @jeffmo es compatible con commonjs/es6/amd. Si pudiéramos incorporar jest como un complemento, probablemente podríamos obtener todo eso de forma gratuita.

++

tenemos muchos proyectos en una gran organización y planeamos usar jest pero somos 100% requirejs. ¿Alguna eta sobre la integración de requirejs?

++

También me gustaría probar jest, pero el proyecto actual en el que estoy está usando RequireJS.

:+1:

Alguien sugirió usar esto como una cuña, ¿alguien lo ha probado?

https://github.com/Jakobo/redefine

_Viable con salvedades_. Implementé una pequeña compilación con nodefy en un repositorio aleatorio que podría funcionar como un recurso provisional . Consulte scripts.cjs en paquetes .

Prueba de fuego: los alias de su módulo AMD se alinean con el módulo correspondiente en node_modules . Si la prueba de fuego falla, pero está desesperado, podría nodefy módulos AMD puros y/o agregar enlaces simbólicos a node_modules, pero la idea me entristece. Desde mi perspectiva, los dispositivos externos que uso tienden a implementar UMD e instalarlos mediante npm en nombres alineados con mis alias de AMD, sin mayor problema.

(Revisé uRequire antes de nodefy, pero la plantilla de CommonJS lo hace funcionalmente equivalente a nodefy; tomaré la herramienta específica. También revisé amdefine, pero jest usa la coincidencia de expresiones regulares en 'requerir'; tal vez haya un AMD anónimo ángulo? Siempre está UMD, pero codificar UMD con referencias dispersas de document suena a malos modales).

+1

++

Estamos usando react, backbone y requirejs en todo nuestro nuevo código del lado del cliente. Me encantaría poder usar bromas y aliviar un poco el dolor de las pruebas de reacción. Sería bueno bajar las cosas al nivel de la unidad. Actualmente, nuestras pruebas para el código de reacción se realizan con rspec y un controlador web. Si bien esto funciona, es menos que ideal por razones obvias.

¿Hay alguna solución práctica todavía? El principal problema con el que me encuentro son las declaraciones de definición que envuelven los componentes de reacción.

+1

@petehunt me encendió Webpack, así que esto también es algo a considerar.

+1

¿Puede alguien señalarme un ejemplo de jasmine/webpack o jest/webpack ejecutando pruebas de navegador con cobertura de código?

++

¿Cuándo podemos esperar soporte para requirejs?

+1

+1

+1

+1

+1

+1

Si usa module.exports en lugar de return para su llamada definida, puede agregar esto a su preprocesador.

Funciona para mí :pulgar arriba:

// 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 para el soporte de RequireJS

+1

@charliedowler ¿Le importaría ilustrar un poco más este enfoque? Lo estoy probando y me encuentro con un par de problemas. comencé agregando

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

Sin embargo, estoy usando return , por lo que recibo un error del analizador del preprocesador. Pensé que podría escapar extendiendo el RegEx para que coincida también con el último retorno. Pero no parece estar funcionando en absoluto. Sigo recibiendo el error "declaración de devolución ilegal". Probablemente algo esté mal con la expresión, y no la está captando.

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

¿Hay alguna forma de que escriba src en la salida estándar? Un simple console.log no funciona.

Y, por último, suponiendo que haga que todo esto funcione. ¿Cómo estás manejando las dependencias? ¿Como, por ejemplo, React?

+1

¡Ay! Había estado jugando (y disfrutando mucho de la broma). Intenté incluirlo en un proyecto real hoy y descubrí que no se requiere soporte de JS: sollozo: ... factor decisivo para todos los proyectos "reales" actuales. Triste de verdad. ¡Sin duda fue una idea emocionante!

:+1:

+1

+1

:+1:

:Pulgares hacia arriba:

:+1:

:+1:

Así que resolví esto usando webpack para compilar mis módulos y pruebas de AMD juntos. Esto me permitió usar también todo tipo de cargadores adicionales con mis pruebas. https://github.com/ninjapanzer/Backbone-Flux-React-Webpack

:+1:

+1

+1

+1

Gracias por informar de este problema y apreciamos su paciencia. Hemos notificado al equipo central para obtener una actualización sobre este problema. Estamos buscando una respuesta dentro de los próximos 30 días o el problema puede cerrarse.

+1

@facebook-github-bot-4 por favor hazlo!

+1

+1

++

He estado trabajando en Jestpack, que es un reemplazo de 'HasteModuleLoader' de Jest para admitir Webpack. Como resultado, significa que puede usar cualquier sistema de módulos compatible con Webpack, incluido AMD.

En una nota al margen, ¿alguien sabe de algún proyecto de código abierto grande (ish) que use Jest que no sean los que usan módulos acelerados de estilo FB, ya que sería realmente útil para probar el rendimiento de Jestpack?

También he estado trabajando en jest-requirejs que es más un intento de un preprocesador de broma estándar que analiza el archivo de configuración del proyecto main.js luego realiza un deamdify , que elimina el define wrapper, reescribe las rutas requeridas en función de los detalles de la baseUrl y las rutas especificadas de main.js, y luego pasa el archivo transformado a jest como de costumbre.

Sigo trabajando en la sintaxis del complemento/cargador y reescribiendo las rutas jest.dontMock("") , jest.setMock("") y require.requireActual("") dentro del entorno de prueba.

Hola chicos, esto es realmente asombroso. Me gusta la idea de Jestpack y he tenido la intención de hacer que sea mucho más fácil admitir resolutores de módulos adicionales. Finalmente, también quiero renovar el sitio web y recomendar soluciones como Jestpack como parte de la guía Getting Started (que tengo en mente :)). @richardscarrott y @sterpe favor, hágamelo saber si necesita algo.

También cc @mwolson y @ColCh

(Para todos los demás: por favor, dejen de votar comentarios, no es útil. Si quieren algo creado para bromear, envíen una solicitud de extracción. ¡El código gana argumentos! Personalmente, no puedo priorizar funciones solo porque las personas en la comunidad las necesitan y yo no use _todos los cargadores de módulos_ que hay por ahí).

Jestpack es interesante, aunque no soy partidario de tener que crear un punto de entrada por prueba. https://github.com/Ticketmaster/jest-webpack-alias resuelve el problema de manera un poco más genérica, a costa de un preprocesamiento y posibles errores aún no descubiertos debido a la reimplementación del código de resolución del módulo del paquete web.

Además: las guías de introducción probablemente deberían mencionar que es una buena idea limitar en qué archivos se ejecuta su preprocesador, si tiene uno, de lo contrario, ralentiza considerablemente las ejecuciones de prueba.

los preprocesadores solo se ejecutan una vez y puede proporcionar una función de clave de caché. jest no volverá a ejecutar su preprocesador si un archivo no ha cambiado.

Puede ser, pero incluso la primera ejecución fue suficiente para agregar unos ~10 segundos a la ejecución de nuestro conjunto de pruebas.

De acuerdo en que eso no es rápido. En FB, la primera ejecución tarda casi el doble que las ejecuciones posteriores, pero personalmente no veo ninguna otra para resolver esto: estamos usando babel y otras transformaciones personalizadas en FB; no podemos ejecutar pruebas sin un preprocesador :)

El almacenamiento en caché del preprocesador me estaba mordiendo mientras desarrollaba el preprocesador requirejs. En su mayoría, sigo usando [email protected], que no tenía almacenamiento en caché, creo.

¡Debería funcionar bien con 0.5!

Webpack es muy rápido en modo dev-watch.

Porque:

1. Webpack mantiene su tiempo de ejecución en la memoria (sin recargas)
2. El código fuente compilado también se encuentra en la memoria.

Entonces, en mi preprocesador Jest, implementé solo (2) puntos.

En resumen , un paquete ( memoria FS y ejecute casos de prueba en la memoria FS .

Ese es mi punto de vista...

Pero ahora tenemos otro problema: no es posible inyectar memoria FS en Jest por ahora.

Pensé en usar la API de caché de Jest privada, para inyectar la fuente compilada directamente en el caché. Puede ser que sea un truco, así que me equivoqué aquí: jest-webpack/issues/4#issuecomment-98623189

Ah, debo mencionar que Karma con Webpack como preprocesador también funciona muy lento. Entonces, creo que la caída principal del rendimiento se debe a las recargas del tiempo de ejecución del paquete web entre archivos.

@cpojer Pensé que era su intención eventualmente hacer que los cargadores de módulos fueran configurables, ya que ya estaba desactivado, así que pensé en intentarlo con Jestpack. El único problema real con el que me encontré fue comprender la lógica para descubrir simulacros manuales para node_modules https://github.com/facebook/jest/issues/509 , terminé con una solución que tenía sentido para mí, pero si Si puede proporcionar alguna información sobre ese problema, sería bueno alinear el cargador de módulos de Jestpack con HasteModuleLoader.

@mwolson La razón por la que Jestpack usa un punto de entrada separado por archivo de prueba es para garantizar que aún pueda aprovechar los múltiples procesos de Jest.

moduleLoader ya se puede especificar como parte de la configuración, en realidad.

++

A nosotros también nos gustaría esto. Jest parece una pieza de software increíble, pero no puede reescribir todo lo que tenemos para dar cuenta de que no es compatible con RequireJS.

+1

¿Alguien de la comunidad está interesado en trabajar en esto? Estaría feliz de apoyar a las personas a través de esto y hacer un complemento oficial de Jest. Es poco probable que invirtamos mucho en esto en FB en el corto plazo. El equipo de Jest es muy pequeño (1,5 personas) y, lamentablemente, no podemos ponernos a trabajar en todas estas funciones.

Según el estado actual de la comunidad de JavaScript y el estándar, no parece que require js tenga un gran futuro para la creación de código JavaScript. Ahora tenemos un sistema de módulos estandarizados en ES2015. Babel y Jest ahora están completamente integrados y funcionan bien juntos. Recomendaré a cualquiera que cambie a los módulos CommonJS o ES2015, lo que pondrá a su disposición más herramientas listas para usar.

require JS también tiene un documento aquí sobre cómo convertir CommonJS a require.js que se puede usar para implementaciones de producción, consulte: http://requirejs.org/docs/commonjs.html

Personalmente, no veo ninguna ventaja en escribir código usando require JS. También estaría feliz de ayudar a escribir un codemod que pueda ayudar a transformar las bases de código JS requeridas a CommonJS. Otro desafío podría ser escribir un complemento de babel requireJS para CommonJS y extraerlo en el preprocesador de Jest.

@cpojer Tuve algo de éxito con el enfoque del preprocesador aquí https://github.com/sterpe/jest-requirejs/blob/master/index.js pero solo implementé una transformación para los complementos !text/ hasta ahora. Nuestro equipo se alejó de requirejs por completo, por lo que no he tenido una razón para continuar por ese camino.

Estoy de acuerdo, veo poco valor en el uso de RequireJS para crear código. Para mí, tiene sentido compilar el código del módulo CommonJS/ES2015 para requirejs para la producción, pero no parece genial escribir código con este estilo manualmente.

Acabo de hacer la migración de RequireJS a webpack. Hay más de 300 componentes en nuestra base de código. Todo el proceso fue sorprendentemente fácil e indoloro.

La herramienta que he usado fue https://github.com/Skookum/recast-to-cjs para convertir código de estilo AMD a CommonJS.

Además, con la ayuda de https://github.com/facebook/jscodeshift , migramos nuestra base de código de React 0.11 a 0.14 en unos pocos días.

Espero que esto pueda ayudar a alguien en la misma situación.

@tendant agradable! Eso es exactamente de lo que estaba hablando antes :) Me alegro de que te haya funcionado tan bien.

Aquí está mi trabajo:
https://github.com/1twitif/testRequireJSAmdModulesWithJest
Funciona al menos para este caso de uso:
http://stackoverflow.com/questions/33889662/not-able-to-load-amd-modules-through-jest

Dado que esto está cerrado, ¿eso significa que Facebook no agregará soporte para esto?

Si por Facebook te refieres a mí, entonces sí, es poco probable que haya soporte "oficial". Eso no debería impedir que contribuyas a Jest y obtengas esta función, pero creo que la mayoría de las personas se han pasado a los módulos ES o CommonJS en estos días.

Si lo se. Desafortunadamente, no puedo alejarme de estas dependencias porque es por trabajo.

babel-plugin-transform-amd-to-commonjs puede resultar útil para resolver el problema de Jest+AMD, especialmente si ya está usando algo como babel-jest.

Configuré un proyecto de ejemplo que muestra cómo puede hacer que Jest requiera archivos AMD de manera transparente al ejecutar la transformación en el entorno de prueba.

No estoy seguro de los detalles de tal enfoque en un proyecto real, en particular, un buen enfoque para compartir configuraciones entre Jest/RequireJS/Webpack/etc. La compatibilidad de Jest con el archivo de configuración .js sería un paso hacia una solución más reutilizable (consulte https://github.com/facebook/jest/issues/2140).

@msrose esto es increíble. Muchas gracias por compartir esto.

Entiendo que este es un problema antiguo. Una transformación simple podría funcionar:

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

Creo que la transformación de AMD -> CJS se puede hacer de varias maneras, por ejemplo, deamdify , envoltorio inyectado, etc. El problema, aún sin resolver, es Require-style loader/plugin syntaxes. Esas son las cosas como fooTemplate = require('tpl!foo.tpl') y barJson = require('json!bar.json') (como relativamente comunes). Pero hubo muchos de estos y los proyectos de require-js mundo real están llenos de este tipo de sintaxis.

Sería genial si hubiera una manera fácil de reutilizar directamente los require-js complementos existentes en el sistema de transformación que finalmente alimenta el cargador de módulos de jest |.

+1

ReferenceError: define is not defined

+1

FALLA srcApp.test.js
● No se pudo ejecutar el conjunto de pruebas

ReferenceError: define is not defined

Deberías usar umd en lugar de amd. Si eso no es factible, debe agregar una transformación (por ejemplo, el complemento babel vinculado anteriormente).

Cuando se trata de la sintaxis loader! , no la admitiremos (tampoco la admitimos para Webpack). La solución consiste en transformar las importaciones (eliminando los cargadores) y dejar que Jest se transforme usando su configuración transform . Discusión relacionada: #4868