Upgrading to 0.8.0 will break imports from outside of the test's directory

[adregan]

If you are reporting a bug, please fill in below. Otherwise feel free to remove this template entirely.

Can you reproduce the problem with latest npm?

Yes. npm 4.0.3

Description

After upgrading to react-scripts 0.8.0 tests that import files or utilities from outside the current testing directory return 'test-file-stub' as the default (and undefined, of course, for any destructured imports).

Expected behavior

In the prior version of react-scripts, importing utilities into tests worked as expected. If you had a utils directory in your src and you imported it into a test running in another directory in src, you would have access to to the imported code. For example:

src
├── utils
│   └── range.js
└── parsers
    └── books.js
    └── books.test.js

Where in the test file books.test.js:

import parser from './book';
import range from '../utils/range';

console.log(parser);
console.log(range);

const generateFakeBook = (n) => ({title: `Hello ${n}`, author: 'Who Ever'});

it('should parse the book', () => {
  for(let n in range(10)) {
    expect(
      parser(generateFakeBook(n))
    ).toEqual({
      title: '', 
      author: ''
    });
  }
});

The test would run and if you logged out the range function, you would see that it was the function you expected. In the prior release, you could make use of your utility functions in your tests as well as import other items for assisting in your testing.

Actual behavior

If you log out range, you'll see test-file-stub. This happens with any import outside of the directory with the test.

Environment

Run these commands in the project folder and fill in their results:

1. npm ls react-scripts (if you haven’t ejected):

react-scripts@0.8.0

2. node -v:

v7.2.0

3. npm -v:

4.0.3

Then, specify:

1. Operating system:
   Mac OS X 10.11.6

2. Browser and version:
   Firefox 50

Reproducible Demo

I've created 2 versions to show the behavior in 0.7.0 and 0.8.0 and included them in this repo: https://github.com/adregan/create-react-app-issue

[adregan]

I should note that if you remove this line:

https://github.com/facebookincubator/create-react-app/blob/6e0081363265c055075777af77363a38a0111417/packages/react-scripts/utils/createJestConfig.js#L23

the test will pass.

Also, they will pass if you revert the regex change from this commit: a298cbb

[kentcdodds]

This appears to be related to #1147

[fson]

The problem seems to be that the moduleNameMapper regex in Jest is matched before mapping the module name to a file path. So even though the regex added in #1077 correctly mirrors the webpack loader setup we have, Jest only sees ../utils/range and matches that, instead of /absolute/path/src/utils/range.js, which would not be matched because it has the .js extension.

Now it would be great if Jest allowed matching on the full path instead of just the module name, but since it doesn't seem to be possible at the moment, it looks like we need to revert the moduleNameMapper regex to the previous whitelist. We can't tell if a module is a JS module by just looking at the module name.

[fson]

I've just published react-scripts 0.8.1 with a hot fix for this issue.

I'll reopen #667 to discuss how to get the same behavior as our webpack loaders have (any unknown file extensions treated as a file resource) back to the Jest configuration.

[adregan]

Thanks for getting the hot fix out so quickly. 👍

[kentcdodds]

Yes, thank you very much! Really appreciated!