Support for RequireJS

[eldh]

If I understand it correctly, there is currently no way of using this with RequireJS rather than CommonJS style require(). Are there any plans of adding support for RequireJS? Is it even feasible?

[skarankevich]

++

[jeffmo]

It's on our roadmap to support module system add-ons for Jest (like require.js, es6 modules, etc), but unfortunately we're not quite there yet.

Let's leave this issue open to track progress on this, though -- I think it would be pretty useful to support require.js loaders

[petehunt]

@jeffmo webpack supports commonjs/es6/amd. If we could bring jest in as a plugin we could probably get all that stuff for free.

[riddla]

++

[cliren]

we have many projects at a big organization and planing to use jest but we are 100% requirejs. Any eta on requirejs integration?

[drichert]

++

[danielabar]

I would also like to try out jest, but current project I'm on is using RequireJS.

[percyhanna]

👍

[ghost]

Someone suggested using this as a shim, has anyone tried it?

https://github.com/Jakobo/redefine

[popham]

Feasible with caveats. I implemented a little build with nodefy in some random repo that could do the trick as a stop-gap. See scripts.cjs under packages.

Litmus test: Your AMD module aliases align with the corresponding module under node_modules. If the litmus test fails, but you're desperate, you could nodefy pure AMD modules and/or add symlinks to node_modules, but the idea makes me sad. From my perspective, the externals that I use tend to implement UMD and install by npm to names aligned with my AMD aliases--no big deal.

(I checked out uRequire before nodefy, but the CommonJS template renders it functionally equivalent to nodefy--I'll take the targeted tool. I also checked out amdefine, but jest uses regex matching on 'require'--maybe there's an anonymous AMD angle? There's always UMD, but coding UMD with scattered document references sounds like bad manners.)

[SanderSpies]

+1

[philippotto]

++

[cavebatsofware]

We are using react, backbone, and requirejs in all of our new client side code. I would love to be able to use jest and ease some of the pain of testing react. It would be nice to get things down to the unit level. Currently our tests for the react code are being done with rspec and a webdriver. While this works it is less than ideal for obvious reasons.

Is there any practical workaround yet? The main issue I am running into is the define statements that wrap the react components.

[eriklharper]

+1

[justin808]

@petehunt Turned me on to Webpack, so this is something to consider as well.

[tomrogers3]

+1

[cliren]

Can someone point me to an example of jasmine/webpack or jest/webpack running browser tests with code coverage?

[ds0nt]

++

[Anenth]

When can we expect support for requirejs ?

[Tw1N88]

+1

[s-pmpodolski]

+1

[lilaja]

+1

[charliedowler]

+1

[camacho]

+1

[dgiul]

+1

[charliedowler]

If you use module.exports instead of return for your define call you can add this to your preprocessor.

Works for me 👍

// 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);
  }
};

[hjyao]

++

[donners]

+1

[Markus-ipse]

+1

[sergeylukin]

+1 for RequireJS support

[cpojer]

It should work fine with 0.5!

[ColCh]

Webpack is very fast in dev-watch mode.

Because:

1. Webpack keeps their runtime in memory (without reloads)
2. Compilled source code is located in memory too.

So, in my Jest preprocessor I've implemented only (2) point.

In shorten, a package (Jestpack, right...) on top of Jest and Webpack will resolve all issues with performance - just keep Jest and Webpack runtime in memory, compile files in memory FS and execute test cases in memory FS.

That's my point of view...

But we have another trouble now: It's not possible to inject memory FS into Jest for now.

I thought about using private Jest cache API - for injecting compilled source right into cache. May be it's a hack, so I was wrong here: jest-webpack/issues/4#issuecomment-98623189

[ColCh]

Ah, I should mention, that Karma with Webpack as preprocessor is working very slow too. So, I think that main performance drop is because of webpack runtime reloads between files.

[richardscarrott]

@cpojer I figured it was your intention to eventually make module loaders configurable as it was already optioned out so I thought I'd give it a stab with Jestpack. The only real problem I ran into was understanding the logic for discovering manual mocks for node_modules #509, I ended up just going with a solution that made sense to me but if you're able to provide any insight on that issue it would be nice to align Jestpack's module loader with the HasteModuleLoader.

@mwolson The reason Jestpack uses a separate entry point per test file is to ensure it can still take advantage of Jest's multi processes.

[cpojer]

moduleLoader can already be specified as part of the config, actually.

[tomasPavlacky]

++

[rmilesson]

We would like this as well. Jest seems like an awesome piece of software but can't rewrite everything we've got to account for no RequireJS support.

[anggao]

+1

[cpojer]

Is anyone from the community interested in working on this? I'd be happy to support people through this and make an official Jest plugin. It is unlikely we will heavily invest into this at FB anytime soon. The Jest team is very small (1.5 people) and we can't get to work on all these features, unfortunately.

[cpojer]

Based on the current state of the JavaScript community and standard it doesn't seem like require js itself has a huge future for authoring JavaScript code. We now have a standardized module system in ES2015. Babel and Jest are now fully integrated and work well together. I will recommend anyone to switch to CommonJS or ES2015 modules, which will make more tooling available to you out of the box.

require JS also has a document here on how to convert CommonJS to require.js which can be used for production deploys, see: http://requirejs.org/docs/commonjs.html

Personally I see no upside in writing code using require JS. I'd also be happy to help write a codemod that can help transform require JS codebases to CommonJS. Another challenge could be to write a requireJS to CommonJS babel plugin and pluck it into Jest's preprocessor.

[sterpe]

@cpojer I was somewhat successful with the preprocessor approach here https://github.com/sterpe/jest-requirejs/blob/master/index.js but only implemented a transform for !text/ plugins so far. Our team moved off of requirejs entirely so i haven't had a reason to continue down that path.

[cpojer]

I agree, I see little value in using RequireJS for authoring code. It makes sense to me to compile CommonJS/ES2015 module code to requirejs for production, but it doesn't seem great to write code with this style manually.

[tendant]

I just did migration from RequireJS to webpack. There are more than 300 components in our codebase. The whole process was surprisingly easy and painless.

The tool I have used was https://github.com/Skookum/recast-to-cjs for converting code from AMD to CommonJS style.

Also with the help of https://github.com/facebook/jscodeshift, we migrated our code base from React 0.11 to 0.14 within a few days.

Hope this might help someone in the same situation.

[cpojer]

@tendant nice! That is exactly what I was talking about before :) Glad it worked so well for you.

[1000i100]

Here is my work around :
https://github.com/1twitif/testRequireJSAmdModulesWithJest
It work at least for this use case :
http://stackoverflow.com/questions/33889662/not-able-to-load-amd-modules-through-jest

[granmoe]

Since this is closed, does that mean that Facebook is not going to add support for this?

[cpojer]

If by Facebook you mean me, then yes, it is unlikely there will be "official" support. That shouldn't prevent you from contributing to Jest and getting this feature in but I believe most people have moved on to ES modules or CommonJS these days.

[granmoe]

Yeah, I know. Unfortunately, I can't move away from these dependencies because it's for work.

[msrose]

babel-plugin-transform-amd-to-commonjs can prove useful for solving the problem of Jest+AMD, particularly if you're already using something like babel-jest.

I've set up an example project which shows how you can have Jest transparently require AMD files by running the transform in the test environment.

I'm unsure of the details of such an approach in an actual project - in particular a good approach for config-sharing between Jest/RequireJS/Webpack/etc. Jest support for .js configurations file would be a step towards a more reusable solution (see #2140).

[cpojer]

@msrose this is awesome. Thank you so much for sharing this.

[lijunle]

I understand this is an old issue. A simple transform could work:

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

[sterpe]

I think the transform of AMD -> CJS can be done in multiple ways, e.g., deamdify, injected wrapper, etc. The problem, still unsolved, is Require-style loader/plugin syntaxes. That's the stuff like fooTemplate = require('tpl!foo.tpl') and barJson = require('json!bar.json') (as relatively common ones). But there were quite a lot of these and real world require-js projects are littered with this kind of syntax.

It would be great if there were an easy way to directly re-use the existing require-js plugins in the transform system that ultimately feeds into jest|'s module loader.

[angeloocana]

+1

ReferenceError: define is not defined

[konbernu]

+1

FAIL src\App.test.js
● Test suite failed to run

ReferenceError: define is not defined

[SimenB]

You should use umd instead of amd. If that's not feasible, you should add a transform (eg the babel plugin linked above).

When it comes to the loader! syntax, we won't support that (we don't support it for Webpack either). Workaround there is to transform the imports (removing the loaders) and let Jest transform using its transform config. Related discussion: #4868

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.