doc: add strip-types proposal

Author: marco-ippolito

doc/design/proposal-strip-types.md

@@ -0,0 +1,100 @@
+# Strip Types Design
+
+## Problem
+
+TypeScript support has been for a few years at the top of the list of features that users want to see in Node.js.
+Discussion has been on going for a few years [#43818](https://github.com/nodejs/node/issues/43818), and the main blocker has been the lack of a clear on long term support.
+TypeScript does not follow semver, and the Node.js project has been reluctant to commit to supporting TypeScript in the long term, given that the lifespan of an LTS version is 3 years.
+
+## Proposal
+
+The proposal is to add a new flag to the Node.js CLI, `--experimental-strip-types`, which will replace inline TypeScript types with whitespace.
+No type checking is performed, and types are discarded.
+
+Example:
+
+```typescript
+interface Foo {
+    bar: string;
+}
+
+throw new Error("Whitespacing");
+
+```
+
+Becomes:
+
+```javascript
+
+
+
+
+throw new Error("Whitespacing");
+
+```
+
+>Note that the missing types are replaced with whitespace, so the line numbers are preserved, so that sourcemaps are not needed.
+
+By removing types completely, we can avoid the need to commit to supporting TypeScript in the long term, as the feature is not a full TypeScript implementation. We won't need to worry about breaking changes in TypeScript, as we are not implementing them.
+TypeScript features that cannot be replaced by whitespace, such as enums, will error.
+As in JavaScript files, file extensions are required in `import` statements and `import()` expressions.
+TypeScript features that depend on settings within `tsconfig.json`, such as paths or converting module formats, are unsupported.
+This will solve the long term compatibility issue, but might not be as complete as a full TypeScript implementation.
+
+### Goals
+
+#### Determining module system
+
+TypeScript supports multiple module systems, such as CommonJS, ES Modules.
+We want to avoid the need to parse `tsconfig.json` to determine the module system, as this would require a full TypeScript implementation.
+We want to be able to support `.mts` and `.cts` files, and both module systems in `.ts`.
+
+#### TypeScript only features
+
+TypeScript has features that cannot be replaced by whitespace.
+The most prominent unsupported features that require transformation are:
+
+* `Enum`
+* `experimentalDecorators`
+* `namespaces`
+* `module` declaration
+
+With types stripped, unless transformation is performed, these features will error.
+This is probably the biggest limitation of this proposal, since we are not implementing these features.
+
+#### Source maps
+
+Sourcemaps are currently not supported, but we should consider adding support in the future.
+
+#### Extension guessing
+
+Importing modules without extension is a **no goal**, file extensions are **always** required:
+
+```ts
+import { foo } from './foo'; // it will not work
+import { foo } from './foo.ts'; // it will work
+```
+
+[TypeScript documentation](https://www.typescriptlang.org/docs/handbook/modules/reference.html) suggest that the file extension should be `.js` when importing TypeScript files.
+This is mostly for compatibility with other tools, such as bundlers, so that once the TypeScript is compiled, the extension is `.js`.
+We want to avoid guessing the extension, as this would require require a big overhead.
+
+Example:
+
+```typescript
+import { f, SomeType, SomeInterface } from "./module.js";
+```
+
+This would require Node.js to search on the file system the existance of `module.js` and `module.ts` files, and if they exist, load them.
+The `tsconfig.json` option `allowImportingTsExtensions` may help provide compatibility with other tools.
+
+#### Performance
+
+We should keep in mind that this feature should be fast, and not add a big overhead to the startup time of Node.js.
+We want to be faster that external loaders, without bloating the Node.js binary.
+Given that the initial implementation uses [@swc/wasm-typescript](https://swc.rs/docs/references/wasm-typescript), a wasm implementation of `@swc` we should consider moving to a native implementation.
+This should be a goal as performance is critical.
+
+#### REPL
+
+The REPL should support TypeScript, and the `--experimental-strip-types` flag should be supported.