chore(packages): support pretty-dom esm build #964
Conversation
MatanBobi
changed the title
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 771c190:
|
Codecov Report
@@ Coverage Diff @@
## main #964 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 26 26
Lines 966 966
Branches 293 298 +5
=========================================
Hits 966 966
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
This change will break or existing code does break? What happens to people still on jest 26? |
This change will fix the breaking in jest 27. If this is in fact the way it works, sounds like it will break for users using jest 26 (though it didn't fail our tests). |
That's my main confusion here. If this supposedly breaks jest 26, why doesn't it break our test suite? So let's find out first why #963 pulls in a different version of |
|
Do you want any more info from me? So, if node imports testing-library first, then it will cache v26 of pretty-format for all requests within that process. But if jest imports it first, it will cache v27 against node. I thought that was just the way node works - but maybe I am missing something that jest does? When I add a test resolution to this branch to my jest v27 branch it works. When I add the same resolution to my main branch using jest v26 it still works - my guess is that it is getting v27 of pretty-format but the way it is now imported in this PR is backwards compatible with both v26 and v27. |
A cloneable repro. These error messages do not help me identify the issue. They only show symptoms.
That's not how node's resolution algorithm works. It resolves each package relative to each other (https://nodejs.org/api/modules.html#modules_loading_from_node_modules_folders) If I have jest -> pretty-format@27 and testing-library -> pretty-format@26 then testing-library will always get v26 and jest v27. Everything else is either a bug in node (highly unlikely) or a bug in your package manager/bundler or possibly jest itself. Otherwise semantic versioning would be useless since every package would just get a single version that just happens to be loaded first. I think we're just going to inline pretty-format. We've had two or three issues with it in the past and by inlining |
I was under the same impression you were but then I saw |
|
You are right from a normal node perspective: https://nodejs.org/api/modules.html#modules_module_caching_caveats it sounds like you do not need a repro if you already have plans to fix this. If your stuck and nothing will happen without me making a repro I will attempt to make one. |
|
jest might resolve dependencies overly aggressive. I need pretty format v27 for #907 anyway so it'll be fixed in the next major anyway. Which makes it also safer for people still on jest 26 |
|
@eps1lon wdym when you say overly aggressive? |
It's de-deduplicating packages it shouldn't e.g. v26 and v27 are required by different packages but |
This sounds like a bug to me.. Do you know if that's the wanted behavior? |
I said "might".
I wouldn't know |
What:
This adds support for
pretty-dom27 as it's moved to export default only theformatfunction.Why:
This will fix a break for everyone using jest 27. Resolves #963
How:
Upgrade the dependency and import
pluginswhere it's needed.Checklist:
I'm pretty sure this shouldn't be a breaking change.
docs site - N/A