Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Make Program.sourceFileToPackageName public #53812

Open
5 tasks done
marekdedic opened this issue Apr 17, 2023 · 2 comments
Open
5 tasks done

Feature request: Make Program.sourceFileToPackageName public #53812

marekdedic opened this issue Apr 17, 2023 · 2 comments
Assignees
Labels
Needs Investigation This issue needs a team member to investigate its status.

Comments

@marekdedic
Copy link
Contributor

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
Copy link
Member

@weswigham @sheetalkamat any concerns?

@RyanCavanaugh RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label Apr 25, 2023
@JoshuaKGoldberg
Copy link
Contributor

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:

...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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Investigation This issue needs a team member to investigate its status.
Projects
None yet
Development

No branches or pull requests

4 participants