fix(type-utils): treat custom type roots as external

[RebeccaStevens]

PR Checklist

• Addresses an existing open issue: fixes Bug: v6 typeMatchesSpecifier PackageSpecifier should match custom type roots #6868
• That issue was marked as accepting prs
• Steps in Contributing were taken

Overview

[typescript-eslint]

Thanks for the PR, @RebeccaStevens!

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	189d04a
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/652ede0ff4a9620007242cdb
😎 Deploy Preview	https://deploy-preview-6870--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 91 (🔴 down 4 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.

[RebeccaStevens]

@marekdedic

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 189d04a. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 19 targets

• nx test type-utils --coverage=false
• nx test visitor-keys --coverage=false
• nx run types:build
• nx run repo-tools:postinstall-script
• nx test utils --coverage=false
• nx test scope-manager --coverage=false
• nx test typescript-estree --coverage=false
• nx test rule-schema-to-typescript-types --coverage=false
• nx test parser --coverage=false
• nx test repo-tools --coverage=false
• nx test eslint-plugin-tslint --coverage=false
• nx test eslint-plugin-internal --coverage=false
• nx test eslint-plugin --coverage=false
• nx test ast-spec --coverage=false
• nx run-many --target=typecheck --parallel
• nx run eslint-plugin:generate:configs
• nx run-many --target=lint --parallel
• nx run integration-tests:test
• nx run-many --target=build --parallel --exclude=website --exclude=website-eslint

---

Sent with 💌 from NxCloud.

[marekdedic]

Oh, great! I was going to write in #6866 that I'd like to port that logic to PackageSpecifier :D

BTW, there'll be a merge conflict with #6780, but no big deal, they're both tiny changes...

[marekdedic]

Adding a test for this would probably be quite convoluted, right?

[JoshuaKGoldberg]

Yip, similar to the other one, seems reasonable but let's test 👍

[marekdedic]

I think this is mixing #6861 and #6868 together - I don't know if that's a good thing, a bad thing, or neither :D

[marekdedic]

Adding our own type declarations for the internal sourceFileToPackageName seems fishy to me, but that's a decision the maintainers need to do.

I presume you are aware of #6861 - however, there has been no response in the corresponding TS issue....

[JoshuaKGoldberg]

Yeah for now I think it's fine. If they change that API we should see breakages in the TS version upgrade PR.

[JoshuaKGoldberg]

@RebeccaStevens I'm hoping to get through the last bits of v6 work today since we're set to launch on Monday. I think that'll just entail merging v6 into this PR's branch and adding a few unit tests - which I'm fine to do on my own, and plan on doing in a few hours. Please let me know if you already started and I can hold off 😄

[JoshuaKGoldberg]

Hmm, yeah, these unit tests are tough. I ran out of time tonight. Will try again tomorrow.

[JoshuaKGoldberg]

😕 I can't figure this out. 9b49480 shows a unit test that I would think should populate program.sourceFileToPackageName, but it's Map(0) {size: 0}. Either I've misunderstood how to use the combination of typeRoots + sourceFileToPackageName in this unit test (more likely), or that currently-internal API isn't made for this use case (also plausible), or there's a bug with sourceFileToPackageName (less likely).

To repro:

1. Put a breakpoint on https://github.com/JoshuaKGoldberg/typescript-eslint/blob/9b4948056790f764b3864badc57823db82cc528e/packages/type-utils/src/TypeOrValueSpecifier.ts#L166
2. Open TypeOrValueSpecifier.test.ts
3. Launch the VS Code debugger for Run currently open type-utils test (F5)
4. Observe that program.sourceFileToPackageName is empty, even though earlier in the call stack (https://github.com/JoshuaKGoldberg/typescript-eslint/blob/959819186291a93e17e99e52973a68f3a352c2f5/packages/type-utils/tests/TypeOrValueSpecifier.test.ts#L146), type is correctly resolved to export interface Foo

[RebeccaStevens]

Yeah, I gave up on the test too. I came to the conclusion that internal test API thingy isn't setup to do these sort of tests. I didn't want to open that can of worms of editing that.

If I remember right, local tests I tried using a separate repo passed. I can't really turn those into unit test though.

[JoshuaKGoldberg]

This was unintentionally auto-closed when we merged the v6 branch 🙃 it'll be recreated reopened.

[JoshuaKGoldberg]

Yeah, this is a tricky one. All the existing unit tests still pass, and I couldn't figure out how to add unit tests for the new behavior. It's been sitting for a while... let's ship it. 🤘

Sorry for taking so long!