-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Pass retainAllFiles from haste config #2796
Pass retainAllFiles from haste config #2796
Conversation
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks! If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact cla@fb.com if you have any questions. |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
Hrm, It seems that the tests are failing on windows parsing the JSON output from running the integration test. My initial analysis turned up nothing:
I will have to have a look at why this fails in AppVeyor & Windows but passes in linux tomorrow as it's rather late. |
Nevermind, I was missing the |
Just noticed this has some conflicts, I'll rebase this onto the tip of master later today & fix it up. |
Before completing work on the fix we're adding a test-case for the problem we're fixing. This allows us to demonstrate a scenario where we want to have jest only ignore the files in the testPathIgnorePatterns without making assumptions about node_modules/ paths.
Passing retainAllFiles lets us configure haste to be allowed to not make assumptions about node_modules/ folders while keeping the default behavior.
npm script clean-all was deleting the files in this example so we moved it up a level to avoid the wildcard rm
It seems that the nested jest call doesn't work on windows very well due to the reliance on the hashbang in the jest cli bin file. Other integration tests that use this technique skip the test on windows (I imagine for similar reasons).
Prettier was applied to the jest project some time after the original submission of this ticket. Following the rebase I've applied the changes from prettier from my code for consistency.
f8bd236
to
334a489
Compare
Codecov Report
@@ Coverage Diff @@
## master #2796 +/- ##
======================================
Coverage 63.9% 63.9%
======================================
Files 176 176
Lines 6475 6475
Branches 4 4
======================================
Hits 4138 4138
Misses 2336 2336
Partials 1 1
Continue to review full report at Codecov.
|
For now I prefer not to make any changes here. We'll consider how to improve this in the future. |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
This change is to address the problems blocking create-react-app#1081, create-react-app#607, and is based on the conversation at #2318.
I have poured over the logic in
jest-runtime
andjest-haste-map
related to hownode_modules/
and general ignore patterns worked and read the histories of all the tickets in this chain all the way back to the original discussion about absolute paths increate-react-app
and I have come to the conclusion that the safest way forward here is to simply pass theretainAllFiles
flag forward from thejest.haste
configuration.While looking into modifying hastemap's
_ignore
or_isNodeModulesDir
to support the spec oftestPathIgnorePatterns
I realised that we cannot make it "just work" out of the box without some rather large changes to the way the ignore patterns system works.This is because the core behaviour is designed to treat all
node_modules/
folders as ignored except for specific whitelisted children ofnode_modules/
configured byconfig.haste.providesModuleNodeModules
setting.Originally I figured we could use the test ignored patterns to configure additional rules in the whitelist but the reality is that we're dealing with an inverted problem here. The whitelist exempts certain folders from being excluded, where the
testPathIgnorePatterns
exempts paths. They're contrary and building a complex regular expression to cover the inverse of an exception would leave too many holes or be overly complicated.This led me to feel that we couldn't really keep the
_isNodeModulesDir
logic and make thetestPathIgnorePatterns
override this without changing a core assumption about how jest analyses a project.Conclusion
I feel that making a conscious decision to disable the assumption that a user doesn't want
node_modules/
folders examined for tests and then explicitly crafting ignore patterns for the places they don't want scanned is the safest, least-disruptive, and most apt way forward for this concept.jest
users could not configureretainAllFiles
before.jest-haste-map
intact, meaning the impact on the facebook reliant modules referenced by @cpojer in WIP: haste ignores using testPathIgnorePatterns, not all node_modules #2318 should be unaffectedjest-haste-map
already has a use case for disabling the_isNodeModulesDir
checkcreate-react-app
to document a manner which allows for absolute paths orsrc/node_modules
to be used which was discussed as the preferred way forward in create-react-app#1065Test plan
I have included a new integration test
haste-retain-all-ignore-paths
which demonstrates the selection behaviour for tests with the flag turned on.Additionally I noticed that
Runtime.createHasteMap
did not have any unit tests (or I couldn't find any) so I've included a few verifying that the value is passed through to theHasteMap
properly if provided or defaulted tofalse
if not.The entire project passes lint, flow check, and a full
npm run test
pass with no errors.Lint:
Flow:
Tests: