fix: avoid TypeError when Apollo withDisabledDeprecations is not a function#119
fix: avoid TypeError when Apollo withDisabledDeprecations is not a function#119Chhavi-Mandowara merged 1 commit intodevelopmentfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR hardens the log polling utilities against Apollo Client versions/builds where @apollo/client/utilities/deprecation either can’t be required or does not export withDisabledDeprecations as a callable function, preventing a runtime TypeError during log polling.
Changes:
- Adds a Node
createRequire-based import path to load Apollo’s deprecation utility more defensively. - Guards execution so
withDisabledDeprecationsis only invoked when it’s actually a function, otherwise falls back to executing the wrapped function normally. - Minor refactors/formatting in
watchQuerycall sites and catch blocks.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| } catch { | ||
| void 0; | ||
| } |
There was a problem hiding this comment.
void 0; in this catch block will likely trip ESLint's no-unused-expressions (enabled via eslint:recommended) and fails linting. Prefer an empty catch {} (if allowed) or add a comment / explicit handling instead of a no-op expression statement.
| } catch { | ||
| void 0; | ||
| } |
There was a problem hiding this comment.
Same as above: void 0; inside catch is an unused expression and is likely to fail no-unused-expressions. Use an empty catch or a comment / minimal handling instead.
| } catch { | ||
| void 0; | ||
| } |
There was a problem hiding this comment.
Same issue here: void 0; is a no-op expression statement and may be flagged by no-unused-expressions. Prefer catch {} (or a short comment) to intentionally swallow the error.
| return fn(); | ||
| } | ||
|
|
||
| const handler = (withDisabledDeprecations as () => unknown)(); |
There was a problem hiding this comment.
The new guard that falls back when withDisabledDeprecations is missing or not a function is the core of this fix, but it isn’t covered by tests. Please add a regression test that simulates the module exporting a non-function (or missing) withDisabledDeprecations and asserts withDeprecationsDisabled still runs fn() without throwing.
| const handler = (withDisabledDeprecations as () => unknown)(); | |
| let handler: unknown; | |
| try { | |
| handler = (withDisabledDeprecations as () => unknown)(); | |
| } catch { | |
| // If setting up the deprecation handler fails, fall back to running fn without it. | |
| return fn(); | |
| } |
No description provided.