-
Notifications
You must be signed in to change notification settings - Fork 233
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: removed filter-console dependency and fallback if process.env is not available #624
Conversation
…s not available Fixes #617
if (process.env.RHTL_DISABLE_ERROR_FILTERING) { | ||
return () => {} | ||
} |
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 is the breaking change I referred to in the PR description
@@ -1,24 +1,40 @@ | |||
import filterConsole from 'filter-console' | |||
const consoleFilters = [ | |||
/^The above error occurred in the <.*?> component:/, // error boundary output |
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 slightly loosened what this will match, in case a Wrapper
throws instead of the TestComponent
Codecov Report
@@ Coverage Diff @@
## main #624 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 15 15
Lines 218 235 +17
Branches 29 33 +4
=========================================
+ Hits 218 235 +17
Continue to review full report at Codecov.
|
methods: ['error'] | ||
const error = (...args: Parameters<typeof originalError>) => { | ||
const message = typeof args[0] === 'string' ? args[0] : null | ||
if (!message || !consoleFilters.some((filter) => filter.test(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.
Just to call it out, filter-console
would format the string before testing it against the patter (that's why it had a dependency on util
), but I found this wasn't necessary for the cases we are trying to filter. Not doing this may be an issue if how the calls from upstream are made ever change or if we introduce any new cases in the future (although I don't think that is likely).
process.env = { | ||
...process.env, | ||
get RHTL_SKIP_AUTO_CLEANUP(): string | undefined { | ||
throw new Error('expected') | ||
} | ||
} |
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 couldn't remove process.env
from the test environment all together (other things started to crash), but I could make it error when trying to access the variables.
@@ -142,51 +142,4 @@ describe('error hook tests', () => { | |||
expect(result.error).toBe(undefined) | |||
}) | |||
}) | |||
|
|||
describe('error output suppression', () => { |
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 moved to a new file
let cleanupCalled = false | ||
let renderHook: ReactHooksRenderer['renderHook'] | ||
const cleanups: Record<string, boolean> = { | ||
ssr: false, | ||
hydrated: false | ||
} | ||
let renderHook: ReactHooksServerRenderer['renderHook'] |
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 improved quite a few of the server renderer tests to actually test the behaviour pre/post hydration. Some already did this but others not so I made them consistent.
@@ -1,4 +1,4 @@ | |||
import ReactDOM from 'react-dom' | |||
import * as ReactDOM from 'react-dom' |
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 prevents the import relying on @babel/runtime
for default import interop.
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.
so this works the same either way? interesting. i would expect you to need to add .default
where you used ReactDOM before
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.
It's interesting because import ReactDOM
and import * as ReactDOM
are not equivalent as per the ES6 import spec, but most compilers/bundlers treat them interchangeably. Babel does this by inserting the default import interop helper when there is no default export for the module, like in React/ReactDOM's case. By changing the the import * as ...
, it's actually more correct for these libraries.
export type ServerRenderHookResult< | ||
TProps, | ||
TValue, | ||
TRenderer extends ServerRenderer<TProps> = ServerRenderer<TProps> | ||
> = RenderHookResult<TProps, TValue, TRenderer> |
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 introduced a few server render specific types here to help out in the tests. The technically aren't used by the production code, but they don't hurt it either.
there are uses of |
this looks great! Thanks! |
Good point. They might be used in setup files and get bundled in too, so we should protect them in a similar same way. |
… try/catch is being used
I'm getting cold feet about not pushing it as a breaking change. @joshuaellis what are your thoughts? |
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 think this is fair to assume it's a fix, if I understand correctly, it's all about process.env
not breaking in the browser but using that env
variable will still stop the call, so in theory everyone's tests should run the same.
If someone's done a hack // workaround to solve this themselves then there's a cause it'll break, but you can hardly account for that.
Not quite @joshuaellis. Currently, if someone set With this change, explicit calls to |
Aha, thank you for clearing that up. Then it still sounds like it could be a breaking change, albeit not exactly dramatic, but given previous history we've had with "breaking people's test suites" I think we should play it safe and release as breaking. |
Ok, here we go... |
thanks @mpeyper |
@all-contributors please add @bdwain for bug, review 😄 |
I've put up a pull request to add @bdwain! 🎉 |
🎉 This PR is included in version 7.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
What:
Remove Node specific dependencies to make running tests in a non-node environment (i.e. the browser) is easier to achieve without defining variables or polyfilling APIs.
Why:
Fixes #617
How:
Removed
filter-console
dependency as it was dependant on Node'sutil
module.Also wrapped access of
process.env
variables to catch if undefined and return default values.Checklist:
There is a potentially breaking change here, depending on how you view it. Previously, the
process.env.RHTL_DISABLE_ERROR_FILTERING
check was performed inside thesuppressErrorOutput
function, which was fine when it was first introduced.Later,
suppressErrorOutput
was exposed out of the API so that consumers using thepure
imports could opt into the suppression as well, however, setting theRHTL_DISABLE_ERROR_FILTERING
variable had the possibility of making explicit calls tosuppressErrorOutput
a no-op.I view this as a bug introduced when exposing
suppressErrorOutput
, rather than a breaking change being introduced here now, and I doubt anyone is relying on this odd combination of behaviour, but if others feel strongly I'm happy to either retain the existing behaviour or make this a major bump. Feedback welcome.Finally, I've snuck in a few pieces of cleanup from dropping Node 10 support as well as some small tweaks that makes the final output of the code not rely on
@babel/runtime
at all. I'm loathed to remove@babel/runtime
dependency all together as I feel it's too easy for a change to introduce the need for it again, which is relatively unknown until you publish a broken version.