[3.14.0] Deprecation false positives while running tests

[tiagojufr]

Issue Description

When I run my tests using MockedProvider I get 2 deprecation warnings:

[InMemoryCache]: `addTypename` is deprecated and will be removed in Apollo Client 4.0. Please remove the `addTypename` option when initializing `InMemoryCache`.
[cache.diff]: `canonizeResults` is deprecated and will be removed in Apollo Client 4.0. Please remove this option.

I'm not using addTypename nor canonizeResults in all my codebase.
These deprecation warnings don't show up when I run my app, only when running tests with vitest.

Link to Reproduction

https://codesandbox.io/p/devbox/focused-drake-l73wfw

Reproduction Steps

1. Open reproduction codesandbox
2. Run npm t
3. Check console for stderr

@apollo/client version

3.14.0

[jerelmiller]

Hey @tiagojufr 👋

That is interesting, especially since that addTypename warning should be muted when the client instance is created inside MockedProvider.

I'd like to take this back to the team and see if this is something we want to patch or not. We are trying to limit patches in 3.x now that 4.0 is out.

For now, would you be ok with a workaround until I have an answer here? You can mute all deprecation warnings with a global which you should be able to use in your test setup.

global[Symbol.for("apollo.deprecations")] = true;

If you prefer some of those warnings in your tests to catch existing usages of deprecated options, you can use the withDisabledDeprecations helper instead to mute deprecations for the duration of the test.

import { withDisabledDeprecations } from "@apollo/client/utilities/deprecation";

test('something', async () => {
  // Mute deprecations for the duration of this test
  using _ = withDisabledDeprecations();

  // ...
});

[tiagojufr]

@jerelmiller I'm already using your first workaround in my test setup file, thank you. I just wanted to report the issue as I'm sure this will happen to more users as it's a very common scenario

[mspiess]

Patching with #11570 also works for me, so it's probably related to #9976

[jerelmiller]

@mspiess do you mind elaborating? I'm not quite sure how this issue would be related to the exports field in package.json.

[mspiess]

@jerelmiller sure. Vitest "externalizes" all dependencies by default. Don't ask me about the details but it can happen that vitest loads multiple formats of the same package. When I read your comment about the mutes not working I suspected that they are not working because there are 2 slots in play, when there should really only be one. I ran into a similar issue with react-router recently.

There probably is some way to work around this with vitest's server.deps.external or deps.optimizer settings, but I couldn't make it work.
Then I came across #9976 and tried the suggested workaround.

Edit: In issues of this kind vitest maintainers usually recommend that libraries add the exports field in package.json.

[jerelmiller]

@mspiess oh dang that is super helpful to know! Appreciate the context here and that would make a ton of sense why this might happen. Appreciate the elaboration!