require.context doesn't work in tests

[suchipi]

I sometimes use webpack's require.context to automatically load files from the filesystem. Example:

Directory structure:

- components
  - Button.js
  - Icon.js
  - index.js
- docs.js

index.js:

// `require` in every file except index.js from the current directory, then
// add their default export to module.exports based on their filename.
// eg module.exports["Button"] = require("./Button.js");
const req = require.context(".", false, /^\.\/(?!index).*\.js$/);
req.keys().forEach((fileName) => {
  const exportName = fileName.replace("./", "").replace(".js", "");
  module.exports[exportName] = req(fileName).default;
});

docs.js:

import * as components from "./components";
Object.entries(components).forEach(([componentName, ComponentClass]) => {
  /* generate docs for `componentName` using `ComponentClass` */
});

This example is somewhat contrived because index.js could just be replaced with:

import Button from "./Button";
import Icon from "./Icon";

export { Button, Icon }

but when you're importing hundreds of files, this is both helpful and powerful; it's easy to write a require.context that treats named exports differently, for example:

const req = require.context(".", false, /^\.\/(?!index).*\.js$/);
req.keys().forEach((fileName) => {
  const exportName = fileName.replace("./", "").replace(".js", "");
  // next line changed, now we export both the default export and the named docExamples export
  module.exports[exportName] = [req(fileName).default, req(fileName).docExamples];
});

This pattern allows you to co-locate documentation examples with your code, which discourages documentation getting out of sync with the component.

Although this example only addresses documentation, this pattern can be useful anywhere you have a lot of files with correlated features and enforcing an export signature convention is feasible and discourages code rot.

---

This is all possible using create-react-app today. However, it all breaks when you try to run your tests (in 0.3.0-alpha), because jest (naturally) doesn't use webpack:

Using Jest CLI v14.1.0, jasmine2
 FAIL  src/__tests__/some-test.js (0s)
 Runtime Error
  - TypeError: require.context is not a function

Is require.context "too obscure" of a webpack feature? Should create-react-app start disallowing it or warning about its usage? Where and how do we draw the line on which webpack features should be supported and which should not be?
Or, should we try to support require.context in the test runner enrivonment? If so, where and how do we draw the line on which webpack features should be supported in the test environment?

[gaearon]

Is require.context "too obscure" of a webpack feature? Should create-react-app start disallowing it or warning about its usage? Where and how do we draw the line on which webpack features should be supported and which should not be?

Yep, it is too obscure in my opinion.
I’m happy to take a pull request that adds a lint rule against its usage.

If we don’t document something in howto, we don’t support it.

[gaearon]

Where and how do we draw the line on which webpack features should be supported and which should not be?

I’d say any custom extensions to require are not going to be officially supported, and may break at any time. We don’t actively plan to break them but we may. We do, however, understand that many people need code splitting, so we will keep require.ensure support until we switch to Webpack 2 which offers it via System.import.

[vjeux]

cc @cpojer for evaluating implementing require.context in jest

[cpojer]

I really don't want to add this to Jest. require.context seems like a really bad API and hard to statically analyze. We really shouldn't encourage use of this because something is "hard to type" or long.

This should be solvable by a custom __mocks__ file for the index module that exports all of the modules OR creates a Proxy object for the index module that has getters during runtime.

[gaearon]

Yea, I agree with @cpojer here.
It isn’t friendly to ES6 modules either and will break any tooling that assumes them.

[suchipi]

All comments makes sense. Thanks for the discussion.
Future readers: I was able to workaround this by providing mocks for each file that uses require.context, as @cpojer indicated. But as it is unsupported, I do not recommend using it. I plan on changing my code to not use it.

[suchipi]

Just had a thought: what about stuff like:

require("./something/" + name);

Webpack generates a context module when you pass a dynamic path like this (which is the same kind of module that can be manually created with require.context).
Should this behavior also be warned against? Normal node can do dynamic requires, but imports must be static.

I'm not sure what the behavior in jest is for this case, but I expect that it works, though mocking it might be inconvenient.

[cpojer]

Inside of tests this is fine, you can require dynamic modules as much as you'd like and sometimes that is useful.

Outside of tests it is bad because those cases cannot be statically analyzed.

[draperd]

Although I understand the rationale of the decision on the discussion, I thought it might be valuable to provide another use case of require.context as additional feedback:

In my case I'm using create-react-app to develop components that will be imported and consumed by other projects within our organizations. Part of the requirement is localization and both with my own implementation and using react-intl I've needed to use require.context in order pass an argument to a utility function or HoC enhancer to provide a path the localization bundles for that component.

Without require.context Webpack will attempt to load the bundles in a location relative to the utility function and not the component.

So with require.context I can do this...

i18nUtils.addBundle({
    requireContext: require.context("./i18n", false),
    bundleName: "BaseField"
})

...and have the utility function merge the message like this...

bundleMessages = input.requireContext(`./${input.bundleName}.${language}.json`);
merge(this.messages, bundleMessages);

Based on other discussions I do understand why create-react-app doesn't and should tie itself to proprietary module loading capabilities... however, I just want to highlight another use case of require.context.

One improvement that could be made would be for the linting to output a warning or even an error when require.context is used in the project source... because require.context works fine in the application, but then fails in the tests.

So this is of course a symptom of a broader requirement for simple i18n support, but I came across this thread when searching for information on the error message I was seeing.

[gaearon]

Doesn't this mean you're bundling all locales all the time?

[draperd]

Well, unfortunately yes...

But that's a symptom of doing this entirely on the client-side. Our previous Spring MVC based solution handled localization bundles on the server so that the client only received bundles for the requested locale.

However, in the context of what we're trying to do (which is to provide re-usable components for 3rd parties to use in custom applications accessing REST APIs of our platform) it's a something that we need to live with.

The issue is somewhat mitigated by trying to ensure that we only load messages of the components that are used. A simpler but more expensive solution would be to just provide a single bundle containing all of the messages for all of the components (especially given that some of the components don't even have a localization requirement).

I completely agree that loading multiple bundles is not ideal, but without having control of the server this is the best solution. Again, this problem is unlikely to be common I would assume that most people just want to build their own application.