Ship stripInternal as officially supported compiler option

Suggestion

🔍 Search Terms

I have looked through all issues while searching for stripInternal. While many mention this option and numerous comments mention that it is not officially supported, I couldn't find a definitive issue to discuss what would be required to officially ship shipInternal.

✅ 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

The stripInternal compiler option is currently marked as "internal": https://www.typescriptlang.org/tsconfig#stripInternal This issue would track what is required to ship stripInternal as an officially supported compiler option.

📃 Motivating Example

The compiler option looks interesting and would address several cross-folder problems we are observing in Chrome DevTools. Most commonly, we want to separate code out in separate files to keep functionality modular, but this will cause all symbols to be available in the .d.ts files. We sometimes don't explicitly export a particular file in our "entrypoints" to prevent other folders from using these symbols, but this is not always possible. Marking some exports as internal implementation details of a particular module would resolve that issue.

However, at Chrome DevTools we don't want to rely on internal, not officially supported compiler options. Therefore, if this option becomes officially supported, we can adopt it in our codebase to cleanup numerous exported symbols that are effectively internal implementation details.

💻 Use Cases

Factoring out code into separate files when they should remain internal implementation details would allow for a tighter control on what code is allowed to be used by different modules.

For example, in our formatter implementation that runs in a worker, we define the Ecmascript version we support in the same file as our tokenizer. However, this constant should effectively only be used by formatter_worker and not by any other module. Therefore, if we would be able to mark it as @internal, we can safely use this constant, without accidentally introducing unwanted usages at other places in the codebase.

Note that the same logic as above would be valid for AcornTokenizer itself. It is an implementation detail of the formatter_worker and outside modules should not be using it. We use this pattern a lot, where we implement various panels in subpanels. These subpanels are not intended to be used on their own, but are factored out into separate files for readability and maintainability purposes.

Start by reviewing the current stripInternal compiler option and its tsconfig documentation, then compare them with the Chrome DevTools use cases described here. Identify the requirements for official support and any compiler or documentation areas that would need changes; done requires an agreed scope and design, which this issue does not yet provide.