🔍 搜索词
organizeImports type
✅ 可实现性检查清单
- 这不会对现有的TypeScript/JavaScript代码造成破坏性的改变
- 这不会改变现有JavaScript代码的运行时行为
- 这可以在不根据表达式的类型发出不同的JS的情况下实现
- 这不是一个运行时特性(例如库功能、带有JavaScript输出的非ECMAScript语法、JS的新语法糖等)
- 这不是要求添加一个新的实用类型： https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- 这个特性将与我们设计目标的其他部分一致： https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals
⭐ 建议
将值和类型导入合并为一个导入。
📃 激励示例
如果我有以下代码
import { CascadeFunction } from "@rcompat/async/cascade";
import cascade from "@rcompat/async/cascade";当我运行 organizeImports 时，它将被合并为
import cascade, { CascadeFunction } from "@rcompat/async/cascade";然而，如果我有
import type { CascadeFunction } from "@rcompat/async/cascade";
import cascade from "@rcompat/async/cascade";运行 organizeImports 将无济于事，尽管我希望它能将导入合并为
import cascade, { type CascadeFunction } from "@rcompat/async/cascade";💻 用例
- 你打算用这个做什么？
保持导入整洁。 - 当前方法存在哪些不足之处？
导入可能会加倍，尽管运行organizeImports,我可能没有注意到。 - 在这段时间内你正在使用什么解决方法？
如果发现，我会手动合并。
3条答案
按热度按时间nkoocmlb1#
请注意，当它们完全等价时，这些合并，例如：
jdzmm42g2#
正如@RyanCavanaugh指出的，当它们完全等价时，它们会合并。我认为这个建议应该被拒绝，因为它会引入有损行为。
想象在这个例子中，从：
在那种情况下，不会生成运行时导入。但是，假设你添加了一个单独的运行时导入(可能在重构期间临时自动导入),并且这个建议被实现了：
现在，再三考虑，删除那个新的导入。结果仍然包含一个空的运行时导入，而不是原始的有意类型导入：
请注意，上面的情况并不等价，也无法自动转换回
import type,因为有时候你希望有一个运行时导入(对于不纯模块),而有时候你不需要，所以需要保留写入的导入。68bkxrlz3#
感谢你的解释。虽然这是一个足够合理的理由来拒绝这个建议，但我并不清楚
import type { a } from "b";和import { type a } from "b";在语义上是否等价。我理解的方式，以及我假设大多数人会理解的方式是，将
type放在大括号外面相当于在大括号内的各个导入前面写上
type,以防万一都是类型导入。也就是说，前者只允许类型导入，而后者允许组合值和类型导入，因此，如果大括号内没有值导入，就相当于前者。