TypeScript Node16模块解析不检查副作用导入 ```markdown Node16模块解析不检查副作用导入 ```

7tofc5zh  于 6个月前  发布在  TypeScript
关注(0)|答案(8)|浏览(101)

Bug报告

🕗版本与回归信息

这是我在每个版本中尝试的行为,我查阅了关于这个问题的FAQ条目。

⏯ Playground链接

带有相关代码的Playground链接

💻代码

// @module: Node16
import "./file";

🙁实际行为

TypeScript什么都没说。

🙂预期行为

我希望TypeScript能告诉我 .js 是缺失的,就像它在任何其他类型的导入中所做的那样。我认为我现在还不明白为什么它不会这样,因为副作用与静态分析无关,所以导入的不正确性不会以任何方式阻止TypeScript完成其工作,但是:

  1. 我还没有能够在bug workbench中设置这个,但是如果文件是从 node_modules 导入的,并且其中有一个与之对应的 .d.ts ,其中包含一个 declare ... ,会发生什么?那个 declare 会被应用吗?
  2. 无论哪种方式,这都是有用的吗?我想ESLint可以填补这个空白,但 seeing how eslint-plugin-import is dragging its feet on import/extensions ,对此几乎没有希望。
    如果之前已经解决了这个问题,很抱歉没有找到。
9gm1akwq

9gm1akwq1#

我相信这最近已经在与@andrewbranch的讨论中提到了。我认为Node16用户可能希望在这种模式下获得一个错误,但很难说-此外,如果这些用户试图将导出Map与捆绑器一起使用,他们需要一个替代选项。

emeijp43

emeijp432#

我认为Node16用户可能希望在这种模式下获得一个错误,但很难说-此外,如果这些用户试图将导出Map与捆绑器一起使用,他们需要一个替代选项。
等等,我感到困惑-为什么这只是对副作用导入的关注?

yuvru6vn

yuvru6vn3#

我也不明白那句话🤔

brgchamk

brgchamk4#

之所以这不是一个不言而喻的选择,是因为在某些捆绑器配置中,为了将全局适用的CSS添加到捆绑包中,这是常见的做法。我们不会检查具有任意扩展名的文件的存在,因此,为了使此解析生效,您必须通过#51435添加一个模式环境模块".*css"styles.d.css.ts中的文件。但对于副作用导入来说,这两种方法都有些无意义,因为在那个声明中编写的类型永远不会被观察到。

我认为我希望模块解析能够说:“这里有一个文件,但我没有读取它,因为它的扩展名不受支持”,这样我们就可以将其视为副作用导入的成功解析。这比仅仅解 debugging 误静默要大得多的变化。

hfyxw5xn

hfyxw5xn5#

也许这个错误只应该在 bundler 分辨率模式下取消静默,假设这仍然是一个计划(我没有密切关注它,因为我更感兴趣的是 minimal --浏览器 ESM 模式--暂时搁置)。那个 CSS 导入在实际工具链中没有意义;即使运行时理解了它,我不得不想象它基本上是一个空操作,原因和 TS 中的原因是一样的。
但是对于副作用导入来说,这两种感觉都有点无意义,因为声明中写入的类型永远不会被观察到。
嗯,理论上讲,如果 .d.ts 包含任何全局声明,那么这些类型(如果存在)可能仍然可以被观察到,对吗?import type 'foo'; 是一个东西吗?

3ks5zfa0

3ks5zfa06#

你是对的,任何全局声明都会被遵守(并且没有 import type "foo" )。如果你只是想全局加载一个CSS文件或者类似的东西,这似乎并不是你想要的。

r1zhe5dt

r1zhe5dt7#

TS与人们导入css或其他工具链无关,作为TS用户,我希望TS在其保证方面保持一致,包括模块存在检查的保证。
"让我们忽略模块存在检查,如果它是一个副作用导入,因为有人可能会导入一个样式表"
就像想象一下,如果他们是游客,就不需要司机在红灯处停下来,因为他们来自的国家可能是允许这样做的。

imzjd6km

imzjd6km8#

出于娱乐,我发送了 #58941,它添加了一个 resolveSideEffectImports 选项;它似乎捕捉到了人们在这里已经提到的所有内容,但在 DefinitelyTyped 上的很多东西实际上是意外损坏的。

相关问题