[transpileDeclaration API] What to do about "has or is using private name" diagnostics

[MichaelMitchell-at]

🔍 Search Terms

isolated declarations transpile transpiledeclaration diagnostic private name

✅ Viability Checklist

• 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Either make ts.transpileDeclaration not report "has or is using private name" diagnostics, or provide a method to easily check whether a diagnostic is related to private names.

📃 Motivating Example

Usage of ts.transpileDeclaration for any project with isolatedDeclarations

💻 Use Cases

ts.transpileDeclaration will report usage of global types such as Pick, Omit, Promise, or project-specific ones, as using private names. These are not really actionable, so I wonder if these diagnostics should just not be reported at all. What I've been doing is to just filter them out. The structured way of doing that is checking the diagnostic code, but there are so many codes to check that I decided to take a more unstructured approach by just checking diagnostic.messageText.includes('private name'). So at the very least, if these diagnostics will continue to be reported, it would be nice if there was some boolean method that says whether or not a given diagnostic is related to private names.

[weswigham]

I think this is just an unfortunate conflation of behaviors in our normal declaration emit errors. Emitting "X is using private name Y" when Y actually just doesn't resolve at all seems wrong - it's not that it's there but inaccessible from here, it's that it's not there at all. In all of these cases, the checker should be reporting a Name Y cannot be found error or the like (if it's run), so I don't think declaration emit should be doubling up on that with its' own confusing error. We probably want to trim "X is using private name Y" errors to just resolvable privates and leave the unresolved names errors to the checker pass.