-
-
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
feat: add default exportConditions
for both jsdom
and node
environments
#11924
Conversation
Codecov Report
@@ Coverage Diff @@
## main #11924 +/- ##
==========================================
- Coverage 67.25% 67.24% -0.02%
==========================================
Files 329 329
Lines 17353 17357 +4
Branches 5074 5074
==========================================
Hits 11671 11671
- Misses 5650 5654 +4
Partials 32 32
Continue to review full report at Codecov.
|
I've removed the custom environment classes from tests to use the new ones that already provides the conditions, so this way they are actually being tested and code coverage doesn't decrease, and also it's removed duplicated code. |
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.
Hey! This isn't safe to do as node
means "anything node can load" which means .node
or .json
files (which isn't supported by ESM) and ESM files (which isn't supported by require
). You can make this decision in your own project, but Jest itself cannot as it depends on user config.
We can probably add a way to configure this so the conditions can be provided by config, but just setting them by default won't work.
browser
is safer, but would create a weird asymmetry imo
Actually, due to #11919 (comment) we might need to do this. Still needs to go in a major release tho |
But, that's exactly the purposse of According to Node.js docs, this is the expected behaviour and usage, so I think it's totally save to add this PR functionality. |
No issues on that, fine for me :-) |
Is this ready to be merged for the upcoming Jest 28? |
Any update on this? What needs to be done so it gets merged? It has lasted two months now... |
Should |
Any update on this? It seems like k-g-a/jest-node-exports-resolver#9 is directly caused by the lacking of |
Any update on this? How can we ver It merged? |
when we start landing breaking changes |
Tests are passing except for a Windows odd one, seems to be a random failure unrelated to this PR. Otherwise, this is ready to be merged. |
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.
thanks! I'll land this when I start landing breaking changes (hopefully next week)
Co-authored-by: Simen Bekkhus <sbekkhus91@gmail.com>
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.
sweet, thanks!
I'm not allowed to make changes to this PR btw, so when the time comes to merge it, I'll need you to resolve conflicts. If you can give me access (https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork) I can handle any conflicts myself 🙂 |
It doesn't shows me that option, maybe are they only for |
I'm allowed in essentially every single PR, don't think I've experienced not being able to outside of deleted branches/forks. Probably because you've opened the PR from the main branch instead of branching off |
It would made sense. Anyway, just ping me and I'll do any needed changes, no issues :-) |
Cool 👍 I'll start landing breaking changes at some point this week |
Great :-) |
@piranna if you rebase now, I think it should be good to land tomorrow 🙂 No current plans to land any features before this, so in theory no conflicts |
Rebase, or just fix conflicts? I've just done the second one. |
Yeah, whatever is easiest for you 🙂 Merging is fine! We squash on merge anyways, so doesn't really matter how messy the commit history on the branch is 😀 |
Then you already have it :-) |
exportConditions
for both jsdom
and node
environmentsexportConditions
for both jsdom
and node
environments
Thanks! |
Welcome! :-D |
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
#11863 adds support for a new optional
exportConditions()
method in custom environments, so it's possible to add extra conditions. In its tests, it add as an example thebrowser
andnode
conditions to custom environments that extends fromjest-environment-jsdom
andjest-environment-node
respectively. In normal execution,node
extra condition is provided by default by Node.js itself, and although not provided by Node.js,browser
is one of the Node.js endorsed ones.This pull-request modify the
jest-environment-jsdom
andjest-environment-node
environments to provide thebrowser
andnode
conditions by default.Test plan
This code is a copy&past of the actual one in the tests, so instead of being used in ad-hoc child classes on the tests or for demo purposses, they are provided as default values for everybody to use.
As a side note, with the PR now that ad-hoc classes could be removed and use the unmodified
jest-environment-jsdom
andjest-environment-node
that this PR provides, so I can update the PR to remove them too, if you want.