Repository: TypeScript
Issue: Ship stripInternal as officially supported compiler option
Labels: Suggestion,Awaiting More Feedback

# 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:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-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](https://source.chromium.org/chromium/chromium/src/+/master:third_party/devtools-frontend/src/front_end/formatter_worker/AcornTokenizer.js;l=192;drc=d7cfd148144b8bc0964ddfab1a2c91980519361c). 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.