Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
adregan opened this issue Dec 3, 2016 · 6 comments
Closed

Comments

@adregan
Copy link

adregan commented Dec 3, 2016

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):

[email protected]

  1. node -v:

v7.2.0

  1. 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
Copy link
Author

adregan commented 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
Copy link
Contributor

This appears to be related to #1147

@fson
Copy link
Contributor

fson commented Dec 4, 2016

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
Copy link
Contributor

fson commented Dec 4, 2016

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
Copy link
Author

adregan commented Dec 4, 2016

Thanks for getting the hot fix out so quickly. 👍

@kentcdodds
Copy link
Contributor

Yes, thank you very much! Really appreciated!

@lock lock bot locked and limited conversation to collaborators Jan 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants