Repository navigation
Upgrading to 0.8.0 will break imports from outside of the test's directory #1145
Description
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:
npm ls react-scripts(if you haven’t ejected):
react-scripts@0.8.0
node -v:
v7.2.0
npm -v:
4.0.3
Then, specify:
-
Operating system:
Mac OS X 10.11.6 -
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
Activity
adregan commentedon Dec 3, 2016
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 commentedon Dec 4, 2016
This appears to be related to #1147
fson commentedon Dec 4, 2016
The problem seems to be that the
moduleNameMapperregex 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/rangeand matches that, instead of/absolute/path/src/utils/range.js, which would not be matched because it has the.jsextension.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
moduleNameMapperregex to the previous whitelist. We can't tell if a module is a JS module by just looking at the module name.fson commentedon Dec 4, 2016
I've just published
react-scripts0.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 commentedon Dec 4, 2016
Thanks for getting the hot fix out so quickly. 👍
kentcdodds commentedon Dec 4, 2016
Yes, thank you very much! Really appreciated!