Allow type annotations in .js files in preparation for Type Annotations proposal

先阅读 #10939 中之前的讨论以及链接的 TC39 Type Annotations 提案。然后检查 TypeScript 编译器目前对 .js 文件中仅限 TypeScript 语法的限制，并确定该选项的范围，包括哪些构造仍然不允许使用。完成的标准是：有一个文档化的编译器选项支持预期的类型化 JavaScript 解析，同时不改变生成的运行时行为。

🔍 Search Terms

allow js file extension

✅ 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

Add an option to allow removing the error "[some feature] can only be used in TypeScript files"

Previous discussion: #10939

The compiler option would allow consuming .js files as if they were .ts files, but with some differences (see below). All type-checking, type-stripping, and code emitting features would remain as-is.

📃 Motivating Example

The Type Annotations proposal is the definite future of JavaScript.

This feature would:

• Enable incremental adoption of the Type Annotations proposal by users
• Enable incremental support of Type Annotations in the TypeScript compiler
• Possibly help push that proposal forward a little more quickly by increased usage
• Spread word that this proposal exists by gaining compiler support in tsc and its release notes

It's true that the exact syntax isn't definite yet, and it will probably be at least somewhat different than current TypeScript syntax.

However, that's exactly why adding initial support for plain TypeScript would not interfere with its eventually sealed syntax.

In other words, the initial support would simply parse it as "typed-javascript" but the TypedJavaScript parser would currently be exactly the same as the TypeScript parser for the time being, and allow gradual differentiation.

It would also be a good opportunity to allow TypedJavaScript mode to disallow namespaces, enums, constructor fields, etc.

💻 Use Cases

1. What do you want to use this for?

Writing future-ready JavaScript.

3. What shortcomings exist with current approaches?

It doesn't take into account the pending type annotation proposal.

5. What workarounds are you using in the meantime?

I can almost get this working with some VS Code hacks, but then tsc complains as soon as I run it.