-
-
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
Support array of paths for moduleNameMapper
aliases
#9465
Conversation
Hi OrkhanAlikhanov! 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 at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks! |
@facebook-github-bot I signed |
Codecov Report
@@ Coverage Diff @@
## master #9465 +/- ##
==========================================
- Coverage 65% 64.99% -0.01%
==========================================
Files 283 283
Lines 12131 12142 +11
Branches 3002 3006 +4
==========================================
+ Hits 7886 7892 +6
- Misses 3604 3607 +3
- Partials 641 643 +2
Continue to review full report at Codecov.
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
Coverage report shows that |
It's manual, please update it 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really solid work, awesome @OrkhanAlikhanov!
Always nice to see that even the low level parts of Jest can be flexible and approachable.
Coverage report shows that
packages/jest-resolve/src/index.ts
some parts are not covered. e2e tests should cover them actually
coverage does not track e2e tests because of the child processes (that's why our overall coverage metric looks so bad), but don't worry it's not a problem :)
CHANGELOG.md
Outdated
@@ -2,6 +2,8 @@ | |||
|
|||
### Features | |||
|
|||
- `[jest-resolve]` Support array of paths for `moduleNameMapper` aliases ([#9465](https://github.com/facebook/jest/pull/9465)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd give this a [*]
scope perhaps, since it's also e.g. config
packages/jest-cli/src/cli/args.ts
Outdated
@@ -377,8 +377,8 @@ export const options = { | |||
moduleNameMapper: { | |||
description: | |||
'A JSON string with a map from regular expressions to ' + | |||
'module names that allow to stub out resources, like images or ' + | |||
'styles with a single module', | |||
'module names or an array of module names that allow to stub ' + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'module names or an array of module names that allow to stub ' + | |
'module names or to arrays of module names that allow to stub ' + |
(as in 'map from regular expressions to [...] arrays of module names')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(also in other file)
@jeysal Hey! Thank you for the in depth review! (also for appreciating my work 🙃) I added 2 more commits also rebased + force pushed. |
I force pushed again because I missed bracket misalignment due to my vscode differ having Even if we add |
Friendly ping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you update the documentation as well?
) | ||
: (moduleName: string) => moduleName; | ||
|
||
const possibleModuleNames = Array.isArray(mappedModuleName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make it into an array in normalize
?
Thinking about it, that might be a breaking change... Hmm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When an error happens we need to properly format error message based on whether it was set as an array or string in configuration. If we normalize it, we will probably lose that information and not be able to properly format error message
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't be too bad to show [path]
even though the user configured path
I guess, but probably not worth it also given the breaking change risk. I'd be happy as is - however one thing I do want to verify when I have some time is whether the extra work of Array.isArray
, wrapping [mappedModuleName]
etc. has a perf impact. I doubt it's significant, but jest-resolve
is quite a hot path so better safe than sorry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could normalize to an array in the constructor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SimenB Not sure I understood that. Is there anything for me to do apart from updating docs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeysal Aren't resolved module paths cached?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this._possibleModuleNames = Array.isArray(mappedModuleName) ? mappedModuleName : [mappedModuleName];
in the constructor of this class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SimenB The problem is we need both the original config entry for the error message and the array one to iterate over here. As long as we don't want to compromise on the correctness of the error message I think this is as good as it gets 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeysal Aren't resolved module paths cached?
Even with caching often running a single test will need to resolve a large dependency tree, just want to be on the safe side as far as perf goes 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the error message can be passed the original config, but in the happy case it won't have to check if array or not
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be happy with this as is, but would like to do some simple benchmarking before merge
) | ||
: (moduleName: string) => moduleName; | ||
|
||
const possibleModuleNames = Array.isArray(mappedModuleName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't be too bad to show [path]
even though the user configured path
I guess, but probably not worth it also given the breaking change risk. I'd be happy as is - however one thing I do want to verify when I have some time is whether the extra work of Array.isArray
, wrapping [mappedModuleName]
etc. has a perf impact. I doubt it's significant, but jest-resolve
is quite a hot path so better safe than sorry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't find a performance impact - no more open points from my side :)
Thanks a lot @OrkhanAlikhanov!
Just missing documentation update and I'm happy as well 👍 |
I updated docs + rebased and force pushed :) |
Thank you guys! It was pleasure collaborating with you on this feature! 🚀 |
We must thank you! |
I'm keen to use this feature but it looks like it isnt part of 25.1.0. Would be great to see a release. |
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
Fixes #8461
Test plan
I've added test cases let me know if I should add more.
I have not updated CHANGELOG.md eventhough PR template suggests it, not sure if I should do it or it's autodone