-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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
Replace ReactShallowRenderer with a dependency #18144
Conversation
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 f3d4d56:
|
Details of bundled changes.Comparing: f9c0a45...f3d4d56 react-test-renderer
Size changes (experimental) |
Details of bundled changes.Comparing: f9c0a45...f3d4d56 react-test-renderer
Size changes (stable) |
When comparing the bundles, I noticed that |
To be fair, adding support for new component types (if even desired) will be a more likely blocker than non-ideal getComponentName names. I don't even think getComponentName is that useful when the stack is almost flat. |
For now, I can sync my fork with the new Block type and cut another release. |
@@ -22,6 +22,7 @@ | |||
"object-assign": "^4.1.1", | |||
"prop-types": "^15.6.2", | |||
"react-is": "^16.8.6", | |||
"react-shallow-renderer": "^16.12.0", |
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.
A bit unfortunate we didn't start with 1.0.0 or similar. So that you could break it more often if necessary. Although I guess nothing prevents you from jumping to 17 later without waiting for us.
To avoid the versioning awkwardness, we can make it |
Blocks are an experiment and definitely don't make sense in the context of shallow rendering. So feel free to ignore them. |
ef13047
to
2462808
Compare
2462808
to
0e3bd14
Compare
0e3bd14
to
f3d4d56
Compare
I think this looks good. I’ll check tomorrow. |
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've tested this in a fresh CRA project and also at FB and couldn't find any issues. I think we can get this in. Thank you! Let's be careful with future releases since we've set this as a caret (^).
Just wondering what kinds of tests you ran exactly, so I could try and run them myself for future releases of the package (maybe even have them run on CI). |
For fresh CRA, I just copy pasted the docs snippet and verified it still passes tests — whether I write ESM+Babel or CJS+require. |
Cool, thanks! But be careful with assumptions about ESM - as far as I know, Jest doesn't support ESM (jestjs/jest#4842), so what it ends up importing is the CJS version anyway. In other words, it doesn't matter what syntax you use at the call site (in your tests). |
@NMinhNguyen The syntax matters because using the The problem is that we run Jest against both against source as it is. In this case Jest (Babel) is responsible for converting the However, now we won't run tests against the source any more. Just the bundle published to npm. So we don't need that compatibility anymore. So now we probably could revert the changes I made to the tests in #18145 |
@sebmarkbage sorry if I'm misunderstanding, but in CRA which points at the published |
Closes #17321.
Summary
I've extracted the shallow renderer out into its own package - http://npm.im/react-shallow-renderer https://github.com/NMinhNguyen/react-shallow-renderer
As discussed with @gaearon on Twitter, I didn't bother with DEV/PROD builds - the UMD build is essentially a DEV build, and CJS and ES just have
process.env.NODE_ENV
checks inline.Test Plan
CI