ES2015 模块语法优于自定义 TypeScript 模块和命名空间@typescript-eslint/no-namespace

Question

我在运行 npm 启动时收到以下错误：

ES2015 模块语法优于自定义 TypeScript 模块和命名空间@typescript-eslint/no-namespace

    namespace InternalThings {...}

我试图研究这个，但它非常令人困惑。

为什么会这样？ 如何解决？

我试图在我的 tsconfig.json 上放置一些标志，但到目前为止没有成功；

Answer 1

这是由以下 lint 规则引起的 lint 错误： https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-namespace.md

如果您发现该规则有用并希望保留它，那么您需要修改您的代码以使用import和export而不是命名空间。 请参阅规则的文档，了解什么是修复。

如果您喜欢该规则，但想禁用该行的规则，请在其上方添加以下内容：

// eslint-disable-next-line @typescript-eslint/no-namespace

如果您不喜欢该规则并想完全禁用它，请编辑您的 .eslintrc 文件以包含以下行：

rules: {
  "@typescript-eslint/no-namespace": "off"
}

Answer 2

要修复此错误，而不是：

export namespace InternalThings {
    export function myFunction() {
    }

    export class MyClass {
    }
}

import { InternalThings } from './internal-things';

InternalThings.myFunction();

您直接公开命名空间的所有成员：

export function myFunction() {
}

export class MyClass {
}

你像这样导入它：

import * as InternalThings from './internal-things';

InternalThings.myFunction();

主要思想是您的模块的用户只能导入他们想要的内容，或者以不同的方式命名您的模块：

import * as CustomModuleName from './internal-things';

CustomModuleName.myFunction();

import { MyClass } from './internal-things';

let field = new MyClass();

Answer 3

错误来自 eslint。 你必须要么忽略配置中的“@typescript-eslint/no-namespace”规则，要么使用 ES6 重写你的代码。

自定义 TypeScript 模块（模块 foo {}）和命名空间（命名空间 foo {}）被认为是组织 TypeScript 代码的过时方式。 现在首选 ES2015 模块语法（导入/导出）

参考https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-namespace.md

Answer 4

修复 Lint 错误，同时保持相同 API

如果您想在不破坏任何当前实现的情况下处理 lint 错误，您可以执行以下操作，但在提交之前您应该真正查看上述答案： https://stackoverflow.com/a/63574739/349659

前

Implementation

export namespace Container {
  export function someCall() { }
  export function anotherCall() { }
}

Consumer

import { Container } from './Container'

Container.someCall()
Container.anotherCall()

后

选项1

// These are essentially private
function someCall() { }
function anotherCall() { }

// We expose them here
// This feels like a step towards CommonJS, but is valid ES Module code
export const Container = {
  someCall,
  anotherCall,
}

选项 2

您还可以将 function 调用直接定义并封装到 object 中，如下所示：

export const Container = {
  someCall() {},
  anotherCall() {},
}

综上所述

如果你有一个庞大的代码库并且想要“快速”安抚你的 linter，你可以像上面那样进行重构。 请务必考虑这个答案https://stackoverflow.com/a/63574739/349659及其背后的原因。

归根结底，不需要更改代码的最快修复方法是简单地关闭此 linting 规则，如此答案中所述： https://stackoverflow.com/a/58271234/349659

如果您从头开始并遇到这个问题，我会考虑使用现代实现作为 linter 提示，但您可能会发现您喜欢命名空间并且也只是想要它们。 如果您是团队的一员，您可能希望首先获得他们的反馈并遵循团队标准。

---

边缘案例和注意事项

我遇到的一种情况是在同一个文件中有多个命名空间。 在这种情况下，您可能会在删除命名空间后发生名称冲突。

例子

前

export namespace Container {
  export function someCall() { }
  export function anotherCall() { }
}

export namespace AnotherContainer {
  export function someCall() { }
  export function anotherCall() { }
}

后

重命名碰撞

在这种情况下，当您删除命名空间时，您可以重命名冲突，同时保持导出，如下所示：

function containerSomeCall() { }
function containerAnotherCall() { }

export const Container = {
  someCall: containerSomeCall,
  anotherCall: containerAnotherCall,
}

function anotherContainerSomeCall() { }
function anotherContainerAnotherCall() { }

export const AnotherContainer = {
  someCall: anotherContainerSomeCall,
  anotherCall: anotherContainerAnotherCall,
}

解耦代码

另一种选择是将它们解耦到自己的文件中。 如果您想维护原始文件的导出，尽管您需要导入并公开它们，这可能看起来是重复的，但可能是朝着更大重构的间歇性步骤（稍后更新导入以指向新文件）。 如果您愿意，这也允许您开始编写更现代的 ESM 代码，同时通过旧模块代理新导出。

Container.ts

function someCall() { }
function anotherCall() { }

export const Container = {
  someCall,
  anotherCall,
}

AnotherContainer.ts

function someCall() { }
function anotherCall() { }

export const AnotherContainer = {
  someCall,
  anotherCall,
}

OriginalFile.ts

export * from './Container'
export * from './AnotherContainer'

我们可以通过旧的原始模块代理新的 ESM 模块。