Pass retainAllFiles from haste config#2796
Pass retainAllFiles from haste config#2796Reanmachine wants to merge 5 commits intojestjs:masterfrom
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-runtimeandjest-haste-maprelated 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-appand I have come to the conclusion that the safest way forward here is to simply pass theretainAllFilesflag forward from thejest.hasteconfiguration.While looking into modifying hastemap's
_ignoreor_isNodeModulesDirto support the spec oftestPathIgnorePatternsI 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.providesModuleNodeModulessetting.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
testPathIgnorePatternsexempts 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
_isNodeModulesDirlogic and make thetestPathIgnorePatternsoverride 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.jestusers could not configureretainAllFilesbefore.jest-haste-mapintact, 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-mapalready has a use case for disabling the_isNodeModulesDircheckcreate-react-appto document a manner which allows for absolute paths orsrc/node_modulesto 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-pathswhich demonstrates the selection behaviour for tests with the flag turned on.Additionally I noticed that
Runtime.createHasteMapdid 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 theHasteMapproperly if provided or defaulted tofalseif not.The entire project passes lint, flow check, and a full
npm run testpass with no errors.Lint:

Flow:

Tests:
