Feature request: Make `Program.sourceFileToPackageName` public

[marekdedic]

Suggestion

🔍 Search Terms

sourceFileToPackageName

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I would like to request Program.sourceFileToPackageName to be marked as public (or rather, un-marked as internal)

📃 Motivating Example & Use Case

In typescript-eslint, I have recently worked on a way to specify a type including its source (local/package/lib). Well, as part of that, we need to know if a type is declared in a particular package (well, or a corresponding @types package). Currently, this is implemented by just checking the type's declaration files for the node_modules/package_name substring - a rather crude approach.

I stumbled upon Program.sourceFileToPackageName, which as far as I understand is TypeScript doing the same thing - recording the package in which the type was declared, if any. So I would like to use that to prevent any possible discrepancy between TS and typescript-eslint. Additionally, it would solve the problem of not everyone having their dependencies in node_modules - with things like type roots and similar.

Corresponding typescript-eslint issue: typescript-eslint/typescript-eslint#6861

[RyanCavanaugh]

@weswigham @sheetalkamat any concerns?

[JoshuaKGoldberg]

FYI @sheetalkamat - we need this API (or an equivalent) in typescript-eslint to properly support node:test in options for the @typescript-eslint/no-floating-promises rule. The chain of causality is:

• @typescript-eslint/no-floating-promises detects Promises that are created (e.g. returned from a function call) but not handled (e.g. stored in a variable)
• node:test intentionally has some of its functions return Promises that generally don't need to be handled: node:test APIs returning Promises clashes with no-floating-promises lint rule nodejs/node#51292
• Enhancement: [no-floating-promises] add an 'allowForKnownSafeCalls' option typescript-eslint/typescript-eslint#8404 tracks adding in an option to allowlist specific APIs, e.g.:

  "@typescript-eslint/no-floating-promises": ["error", {
    "allowForKnownSafePromiseReturns": [
      { "from": "package", "name": "it", "package": "node:test" }
    ]
  }]

• In order to map from node:test to node_modules/@types/node/test.d.ts, we think we'd need Program.sourceFileToPackageName

...however, now I'm not positive what the right strategy is. If a single .d.ts file has multiple declare modules in it, this might not hold up. Do you have any advice for what we should do here?