fix(sinon): use sinonjs__fake-timers rather than alias

[bcoe]

https://github.com/sinonjs/fake-timers appears to have added types which are incompatible
with the current implementation in DefinitelyTyped.

CC: @fatso83

Refs: sinonjs/sinon#2353
Refs: sinonjs/sinon#2352

Please fill in this template.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Add or edit tests to reflect the change.
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm test <package to test>.

Select one of these and delete the others:

If changing an existing definition:

• If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.

[typescript-bot]

@bcoe Thank you for submitting this PR! I see this is your first time submitting to DefinitelyTyped 👋 — I'm the local bot who will help you through the process of getting things through.

This is a live comment which I will keep updated.

1 package in this PR

• sinon on npm, on unpkg
  • owner-approval: @nicojs

Code Reviews

Because this is a widely-used package, a DT maintainer will need to review it before it can be merged.

Status

• ✅ No merge conflicts
• ✅ Continuous integration tests have passed
• 🕐 Only a DT maintainer can approve changes without tests

Once every item on this list is checked, I'll ask you for permission to merge and publish the changes.

---

Diagnostic Information: What the bot saw about this PR

{
  "type": "info",
  "now": "-",
  "pr_number": 52294,
  "author": "bcoe",
  "headCommitOid": "51905f47c56293f8fddf30aa0773da3205a5164d",
  "lastPushDate": "2021-04-09T18:04:40.000Z",
  "lastActivityDate": "2021-04-09T19:24:15.000Z",
  "maintainerBlessed": false,
  "hasMergeConflict": false,
  "isFirstContribution": true,
  "popularityLevel": "Critical",
  "pkgInfo": [
    {
      "name": "sinon",
      "kind": "edit",
      "files": [
        {
          "path": "types/sinon/index.d.ts",
          "kind": "definition"
        },
        {
          "path": "types/sinon/tsconfig.json",
          "kind": "package-meta-ok"
        }
      ],
      "owners": [
        "mrbigdog2u",
        "lumaxis",
        "nicojs",
        "43081j",
        "joshuakgoldberg",
        "gjednaszewski",
        "johnjesse",
        "alecf",
        "SimonSchick"
      ],
      "addedOwners": [],
      "deletedOwners": [],
      "popularityLevel": "Critical"
    }
  ],
  "reviews": [
    {
      "type": "approved",
      "reviewer": "nicojs",
      "date": "2021-04-09T19:03:46.000Z",
      "isMaintainer": false
    }
  ],
  "ciResult": "pass"
}

[typescript-bot]

🔔 @MrBigDog2U @lumaxis @nicojs @43081j @JoshuaKGoldberg @gjednaszewski @johnjesse @alecf @SimonSchick — please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

[43081j]

We should probably double check with someone like @sandersn if this is the right approach. It feels like the recent webpack issue where they also published their own types.

I have a feeling we should just add it as a dependency and a path mapping rather than trying to import the mangled name directly

[bcoe]

@43081j @sandersn the culprit is here, they've been shipping their own types for a while, I think, but they vary significantly between 6.x and 7.x.

I'd advocate shipping a hot fix, if possible, even if this isn't ultimately how the problem is addressed -- refactoring to use the new timer types might be appropriate.

[nicojs]

@bcoe you've pinged me personally and want to help. I think I understand what you're doing here, you're making sure the types from sinon uses the fake-timers that are shipped as a dependency of this project.

I think this is a valid short term fix.

[43081j]

Fwiw I don't think we should be using the mangled name in an import like that (the types package name).

A path mapping would be better. I'm surprised the existing mapping didn't achieve that.

We really need input from a maintainer on that as we have to be very careful around changing dependency chains

[sandersn]

I think I missed it, but is there a reason that @types/sinon can't use add the latest version of @sinonjs/fake-timers to package.json now that it ships its own types?

Even if it's not possible, the import in index.d.ts still needs to read ... from "@sinonjs/fake-timers" -- sinonjs__fake-timers is a name-mangling that only exists in the DT repo, not on npm. I'm not sure why the existing path mapping doesn't work, though.

[bcoe]

@nicojs thank you for taking the time to eyeball -- we have ~100 builds failing right now, is why this is top of mind for me.

@43081j I hear your concern, and want to be mindful since I'm relatively new to this problem space (I don't want to make things worse). Sounds like, due to the popularity of Sinon we need a core maintainer to chime in regardless.

[sandersn]

I just looked at the sinon PR -- I'd much prefer to see sinon's types here on DT update to be compatible with v7 of fake-timers.

To do that, you'll need to

1. add @sinon/fake-timers@7 to package.json (and create package.json if it doesn't exist)
2. Replace the blanket @sinon/* path mapping in tsconfig with an itemized list of the other @sinon/ packages that are still on DT.

[bcoe]

@sandersn where I'm confused, is looking at the existing types I don't see too much overlap with the types now generated in @types/fake-timers:

https://gist.github.com/bcoe/27193d79d6a44d25f83f1caa04ba7162

Feels like this will be a significant breaking change, so unfortunately someone with a deeper knowledge of the problem space than myself might need to take on the work.

[43081j]

I can try tackle it the way Sanders suggested if you like and see where I get to.

I'll have a go either way and see what happens

[bcoe]

@43081j I'm bumping into the issue on a bunch of repos with large test suites, so I can help test an approach you submit.

[typescript-bot]

👋 Hi there! I’ve run some quick measurements against master and your PR. These metrics should help the humans reviewing this PR gauge whether it might negatively affect compile times or editor responsiveness for users who install these typings.

Let’s review the numbers, shall we?

Comparison details 📊

	master	#52294	diff
Batch compilation
Memory usage (MiB)	87.1	88.1	+1.1%
Type count	13225	13225	0%
Assignability cache size	4257	4257	0%
Language service
Samples taken	1614	1614	0%
Identifiers in tests	1614	1614	0%
getCompletionsAtPosition
Mean duration (ms)	349.2	354.0	+1.4%
Mean CV	9.2%	9.4%
Worst duration (ms)	528.8	507.7	-4.0%
Worst identifier	foo	sinon
getQuickInfoAtPosition
Mean duration (ms)	353.8	358.0	+1.2%
Mean CV	10.2%	10.3%
Worst duration (ms)	564.2	521.3	-7.6%
Worst identifier	stub	stub

It looks like nothing changed too much. I won’t post performance data again unless it gets worse.

[bcoe]

closing in favor of #52297.