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

Fix options.moduleNameMapper override order with preset (#3565) #3689

Merged
merged 4 commits into from
Jun 27, 2017

Conversation

markwhitfeld
Copy link
Contributor

@markwhitfeld markwhitfeld commented May 30, 2017

Summary

Adjusted the order so that the options mappings are checked first and then the preset mappings are checked.
The preset mappings can be overridden by the options mappings.
Fixes #3565

Test plan

Modified existing test and added a new test.
Tests passed after making the necessary code changes. TDD FTW ;) !

@markwhitfeld
Copy link
Contributor Author

markwhitfeld commented May 30, 2017

I think that some "prettier" or ESLint checks failed on CircleCi (hard to tell from the output):

/home/ubuntu/jest/packages/jest-config/src/tests/normalize-test.js
842:27 error There should be no space after '{' object-curly-spacing
842:38 error Expected object keys to be in ascending order. 'c' should be before 'e' sort-keys
842:47 error Expected object keys to be in ascending order. 'b' should be before 'c' sort-keys
842:56 error Expected object keys to be in ascending order. 'a' should be before 'b' sort-keys
842:64 error There should be no space before '}' object-curly-spacing

The first an last errors are just some whitespace that my vs code formatting added. I'll fix that.
The middle three are a bit of a problem though. I deliberately ordered my object keys non-alphabetically to make for a better test. I don't believe that this should change. I will add a prettier ignore directive to the code.

(ESLint and prettier do not work after forking and following all the contribution instructions, so a client side check is difficult. Not a great experience I must say... may have just been in a broken state at the point when I forked)

@codecov-io
Copy link

codecov-io commented May 30, 2017

Codecov Report

Merging #3689 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #3689   +/-   ##
=======================================
  Coverage   58.08%   58.08%           
=======================================
  Files         195      195           
  Lines        6751     6751           
  Branches        6        6           
=======================================
  Hits         3921     3921           
  Misses       2827     2827           
  Partials        3        3
Impacted Files Coverage Δ
packages/jest-config/src/normalize.js 85.38% <ø> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 88e2ee8...b932948. Read the comment docs.

@markwhitfeld
Copy link
Contributor Author

It would be great if this could be part of the next release. I am assuming you are doing trunk based dev so I created this pull request for master.

@treveshan
Copy link

wow finally someone solved this!!! #Legend

Copy link

@treveshan treveshan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

@markwhitfeld
Copy link
Contributor Author

markwhitfeld commented May 31, 2017

@thymikee are you able to approve this and merge it?
This should fix an issue in your jest-preset-angular repo too: thymikee/jest-preset-angular#37

@thymikee
Copy link
Collaborator

thymikee commented Jun 1, 2017

Maybe a little background first. Presets may have some very loosely declared mappings, e.g.:

preset:

"moduleNameMapper": {
  "(.*)": "<rootDir>/src/$1"
},

user config:

"moduleNameMapper": {
  "(.*)": "$1",
  "/my-module/(.*)": "<rootDir>/abc/$1"
},

This mapping ("(.*)": "<rootDir>/src/$1") can be overwritten with user config, but as soon as it gets evaluated by jest-resolve, because it's so loose, other mappings (like "/my-module/(.*)": "<rootDir>/abc/$1" are not taken into consideration.

What this PR does is that it lets in a bit hacky way overcome this issue by merging moduleNameMapper from user config first just to get the right order of mappings.

What do you think @cpojer?

@markwhitfeld
Copy link
Contributor Author

@thymikee and @cpojer
Any idea on when this might be merged?
My team is itching to start using jest but this is a blocker for us.

@thymikee
Copy link
Collaborator

thymikee commented Jun 9, 2017

By the time it's not merged (I'm not sure if it will be), you can temporarily copy the preset configuration and adjust it the way you like. It's not a blocker.


test('merges with options and moduleNameMapper preset is overridden by options', () => {
/* eslint-disable sort-keys */
// prettier-ignore
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please enable prettier here and enable sort keys?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review. See my comment above about the sort-keys rule.
I really think that a test for the correct handling of the order precedence of user and preset config should not only give a scenario that could imply that alphabetical order is the precedence of choice. Providing the object properties out of order makes the test more explicit and more resilient in my opinion.
I'm happy to change my test to support the rule and remove the disable if you prefer the following of the style rules over a more resilient test. Let me know ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just thinking that I could alternatively retain the resilience of the test just by changing semantics. Instead of using the object initializer I could create an empty object and then assign each property in separate statements. Please let me know what you would prefer. Thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that sounds reasonable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great...
Which one? The last suggestion? 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@cpojer
Copy link
Member

cpojer commented Jun 9, 2017

I don't really have super strong feelings about this, if you fix up the test code to not opt-out of the code standards from this repo, I'm fine merging it.

@markwhitfeld
Copy link
Contributor Author

The Circleci build failed on my latest commit due to a failure of the 'yarn run danger' step.
I can't see how that is related to my change. Maybe it is a current issue on master or an intermittent failure.
@cpojer could you kick off a rebuild?

@thymikee
Copy link
Collaborator

This also happened on another PR. Cc @orta

@orta
Copy link
Member

orta commented Jun 13, 2017

Weird, that looks like a bug on GitHub's end wrt their API - Danger's making an API call to an open repo, doesn't look like it's being rate-limited either. So I wouldn't expect this to ever fail.

@markwhitfeld
Copy link
Contributor Author

@cpojer looks like that may be an intermittent isue in the one build step. Would you be able to kick off a rebuild, or should I do a small superfluous check-in to get it rebuilding again?

@markwhitfeld
Copy link
Contributor Author

@orta @cpojer @thymikee Does any of you know how I can get a build kicked off again for this merge request?

@markwhitfeld
Copy link
Contributor Author

Thanks @thymikee for kicking off a rebuild.
Unfortunately the build issue still persists. It seems to be a 401 Unauthorized error being returned by github in the 'danger' build step.
Does anyone have an idea of how we could progress this issue?
Do I need to do anything my side?

@thymikee
Copy link
Collaborator

All tests pass, danger token issue is known and there's nothing you can do but wait for your PR to be merged. @cpojer is on his vacation now, so it may take a while.

@markwhitfeld
Copy link
Contributor Author

Hope you have a great time away @cpojer!
Is there anyone else able to help with this pull request?
@aaronabramov maybe?

@michahell
Copy link

michahell commented Jun 22, 2017

This is a really annoying issue with jest. Is there a better way to temporarily overcome this than:

  • manually merging all files from jest-preset-angular so there is only 1 moduleNameMapper config
  • editing/forking the jest-preset-angular package to change the moduleNameMapper config
  • commenting out any imports in code under test that are not js|ts|html refs

?

@thymikee
Copy link
Collaborator

@michahell you can directly copy jest-preset.json to your package.json and remove the mapping as a workaround for now.

@cpojer
Copy link
Member

cpojer commented Jun 27, 2017

This'll need one more rebase, sorry.

@markwhitfeld
Copy link
Contributor Author

Ok, I'll do that now

Mark.Whitfeld added 4 commits June 27, 2017 12:37
Adjusted the order so that the options mappings are checked first and then the preset mappings are checked.
The preset mappings can be overridden by the options mappings.
@cpojer cpojer merged commit 98a6d9d into jestjs:master Jun 27, 2017
@markwhitfeld
Copy link
Contributor Author

Thanks @cpojer!
When is the next planned release?

@cpojer
Copy link
Member

cpojer commented Jun 27, 2017

May 17th, 2019.

@michahell
Copy link

Thanks guys, awesome! I'll postpone writing tests to May 17th, 2019. don't worry, none will notice 😃 😂

@markwhitfeld
Copy link
Contributor Author

Come on @michahell I think that is taking it a bit too far. May 17th, 2019 is a Friday 🍺 ! You will have to get them done on the 16th 😜

tushardhole pushed a commit to tushardhole/jest that referenced this pull request Aug 21, 2017
…jestjs#3689)

* Fix options.moduleNameMapper override order with preset (jestjs#3565)

Adjusted the order so that the options mappings are checked first and then the preset mappings are checked.
The preset mappings can be overridden by the options mappings.

* Fix prettier linting issues

* Fix eslint issues

* Workaround in test for eslint sort-keys rule
@github-actions
Copy link

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.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

moduleNameMapper with preset and additional config - override order
8 participants