Add a compiler option to error on destructuring a string as an array

🔍 Search Terms

string destructuring

✅ 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

{
  "compilerOptions": {
    "allowDestructureStringAsArray": false
  }
}

declare const source: string
const [item] = source
//        ^^^^^ Error: destructuring string as array is not allowed

📃 Motivating Example

The codebase is everchanging. Someone might do a refactor that change an expression from returning an array of strings to returning a single string. TypeScript which was supposed to catch mistakes like this would fail.

-return Object.entries(myObject)
+return Object.keys()
   .sort(([k1], [k2]) => k1.localeCompare(k2))

As you can see in the above example, the developer forgot to also update the .sort line, but TypeScript didn't alert it. This mistake is easy to catch in small code, but real code is much bigger and similar mistake would be harder to detect.

💻 Use Cases

1. What do you want to use this for? Catching mistake during refactoring or code editing.
2. What shortcomings exist with current approaches? There is no "current approaches".
3. What workarounds are you using in the meantime? There is no workaround, eslint doesn't have such rule, and I doubt it cares about TypeScript's types.

issue 中没有指定文件、测试或编译器入口点。首先跟踪编译器选项的定义方式，以及数组解构的类型检查方式。完成的标准是：新增一个选项，可以拒绝将字符串解构为数组，同时默认保留现有行为，并为所示示例添加覆盖。