microsoft / microsoft/TypeScript

Feature request: Make `Program.sourceFileToPackageName` public

Open
#53,812 2 comments 0 reactions 1 assignee View on GitHub

@sheetalkamat is already working on this.

Since Apr 25, 2023.

Needs Investigation
Dominant language
Go
Stars
111k
Forks
14.3k
Avg merge
1d 19h
Merged PRs (30d)
117

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.