fix(type-utils): support matching intersection types in TypeOrValueSpecifier with a PackageSpecifier

[ronami]

PR Checklist

• Addresses an existing open issue: fixes Bug: [no-floating-promises] TypeOrValueSpecifier (allowForKnownSafePromises) doesn't match FastifyRegister #10665
• That issue was marked as accepting prs
• Steps in Contributing were taken

Overview

This PR attempts to tackle #10665 and adds support for matching intersection types with TypeOrValueSpecifier with a PackageSpecifier.

I've written my thoughts about this issue on #10665 (comment).

---

Some more thoughts:

• This also affects LibSpecifier (which I think is correct), though I couldn't find an actual type on TypeScript's built-in lib types to test this on.

• It seems that for nested intersections the specifier won't match (I think this is mentioned here too).

• This is somewhat related to Bug: TypeOrValueSpecifier should allow intersection types (no-floating-promises allowForKnownSafePromises) #9303.

[typescript-eslint]

Thanks for the PR, @ronami!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

---

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint.

[netlify]

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	0d1f7c6
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/678feed6b514e400083dd37d
😎 Deploy Preview	https://deploy-preview-10667--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 97 (🔴 down 1 from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 98 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[nx-cloud]

View your CI Pipeline Execution ↗ for commit 0d1f7c6.

Command	Status	Duration	Result
nx run-many --target=build --exclude website --...	✅ Succeeded	3s	View ↗
nx run-many --target=clean	✅ Succeeded	12s	View ↗

---

☁️ Nx Cloud last updated this comment at 2025-01-23 08:34:56 UTC

[ronami]

I think this test wasn't checking for intersections correctly, as it checked the symbol of the "returned" type.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.17%. Comparing base (31be053) to head (0d1f7c6).
Report is 20 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10667      +/-   ##
==========================================
+ Coverage   87.15%   87.17%   +0.02%     
==========================================
  Files         448      448              
  Lines       15576    15603      +27     
  Branches     4551     4557       +6     
==========================================
+ Hits        13575    13602      +27     
  Misses       1645     1645              
  Partials      356      356              

Flag	Coverage Δ
unittest	87.17% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
packages/type-utils/src/TypeOrValueSpecifier.ts	100.00% <100.00%> (ø)
.../src/typeOrValueSpecifiers/specifierNameMatches.ts	100.00% <ø> (ø)

... and 6 files with indirect coverage changes

[JoshuaKGoldberg]

👍 agreed, this is a good straightforward fix. Nice!

[kirkwaiblinger]

Would we want to check the whole type first and then recurse? I'm not sure it impacts correctness, so it may not matter, but it seems like prioritizing the sad path a bit to check the intersection constituents first?.

All tests passed when I tried:

export function typeMatchesSpecifier(
  type: ts.Type,
  specifier: TypeOrValueSpecifier,
  program: ts.Program,
): boolean {
  if (tsutils.isIntrinsicErrorType(type)) {
    return false;
  }

  const wholeTypeMatches = ((): boolean => {
    if (typeof specifier === 'string') {
      return specifierNameMatches(type, specifier);
    }
    if (!specifierNameMatches(type, specifier.name)) {
      return false;
    }
    const symbol = type.getSymbol() ?? type.aliasSymbol;
    const declarations = symbol?.getDeclarations() ?? [];
    const declarationFiles = declarations.map(declaration =>
      declaration.getSourceFile(),
    );
    switch (specifier.from) {
      case 'file':
        return typeDeclaredInFile(specifier.path, declarationFiles, program);
      case 'lib':
        return typeDeclaredInLib(declarationFiles, program);
      case 'package':
        return typeDeclaredInPackageDeclarationFile(
          specifier.package,
          declarations,
          declarationFiles,
          program,
        );
    }
  })();

  if (wholeTypeMatches) {
    return true;
  }

  if (
    tsutils.isIntersectionType(type) &&
    tsutils
      .intersectionTypeParts(type)
      .some(part => typeMatchesSpecifier(part, specifier, program))
  ) {
    return true;
  }

  return false;
}

[ronami]

Hmm interesting, I don't think it impacts correctness, but I agree it's easier to understand (even if it adds some complexity to the implementation).

I've updated the PR to match this (note that I've included the error-type check in the whole-type closure, even if it's not necessary, it seems simpler to understand).

[kirkwaiblinger]

[JoshuaKGoldberg]

Thanks for the quick turnaround!