Javascript TypeError:未定义的类扩展值不是函数或null

我在尝试创建这些实体时遇到以下错误

TypeError:未定义的类扩展值不是函数或null

我假设这与循环依赖性有关，但在使用表继承和一对多关系时，应该如何避免这种情况

它在

BaseComic\u 1.BaseComic

上抱怨以下javascript

let Variant=class Variant扩展BaseComic\u 1.BaseComic{

这是完整的文件

"use strict";
var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
    return c > 3 && r && Object.defineProperty(target, key, r), r;
};
var __metadata = (this && this.__metadata) || function (k, v) {
    if (typeof Reflect === "object" && typeof Reflect.metadata === "function") return Reflect.metadata(k, v);
};
Object.defineProperty(exports, "__esModule", { value: true });
const typeorm_1 = require("typeorm");
const Comic_1 = require("./Comic");
const BaseComic_1 = require("./BaseComic");
let Variant = class Variant extends BaseComic_1.BaseComic {
};
__decorate([
    typeorm_1.ManyToOne(type => Comic_1.Comic, comic => comic.variants),
    __metadata("design:type", Comic_1.Comic)
], Variant.prototype, "comic", void 0);
Variant = __decorate([
    typeorm_1.ClassEntityChild()
], Variant);
exports.Variant = Variant;
//# sourceMappingURL=Variant.js.map

---

---

---

我也遇到了同样的问题。事实证明我是在循环导入类，这显然是一个限制

---

注意，循环引用似乎也被限制在文件之间，而不仅仅是类型

---

参见其他答案

正如Thomas Jensen在上面的评论中所指出的，循环引用不仅可以出现在类型中，也可以出现在文件中。 在从同一文件导出基类型和派生类型时，我遇到了相同的问题。例如：

// index.ts
export { BaseClass } from "./base";
export { DerivedClass } from "./derived";

---

这是一个容易陷入的陷阱。将此发布在此处，希望它能节省其他人的调试时间。

刚刚遇到此问题，很奇怪。我以

node——需要ts节点/注册路径/到/索引.ts

即使在我按照公认的答案删除了循环引用之后，这个错误仍然失败了

但是，如果我运行

tsc

，它编译得很好，然后即使使用

——require ts node/register…

，它也可以正常运行

---

希望这对其他人有所帮助。

我来这里是因为当用jest执行代码时，它抛出了这个错误。 这是因为在为

jest.config.js

编写

moduleNameMapper

时，对象中元素的顺序至关重要

有一个帮助程序可以从

ts config.json

导入模块名称：

//jest.config.js
const{pathstomodulenamapper}=require（'ts-jest/utils'）；
//在下面的语句中，将`./tsconfig`替换为`tsconfig`文件的路径
//其中包含路径映射（即“compilerOptions.path”选项）：
const{compilerOptions}=require（'./tsconfig'）；
module.exports={
// [...]
moduleNameMapper:pathsToModuleNameMapper（compilerOptions.path/*，{prefix:'/'}*/）
};

---

取自

我也有同样的问题，因为我的编辑器从错误的包中自动导入了

实体

---

一旦我将

import{Entity}从'typeorm/decorator/Entity/Entity'更改为
import{Entity}从'typeorm'；
错误消息消失。
循环依赖可能很难识别。Michael Weststrate有一个关于循环依赖的方法，并提出了一个模式来修复它们

自动循环依赖项检测。

除了使用一种允许可伸缩性的模式之外，您还可以使用一种非常有用的工具，它只需很少的努力就能为您识别循环依赖关系

Madge可以在
.ts
或
.js
文件上运行。我发现在这两个目录中运行它很有用，因为它们可能会由于传输过程而产生不同的结果

对于Typescript.ts文件：

madge --circular --extensions ts <directory_path>

madge --circular <directory_path>

madge——循环——扩展ts

对于Javascript.js文件：

madge --circular --extensions ts <directory_path>

madge --circular <directory_path>

madge——循环
内部模块模式

试试这个例子来解决循环依赖。
您可以找到的详细信息

我在browserify中遇到了一个循环导入问题。它是不一致和奇怪的——修改文件或注释并删除内容，然后重新运行有时会使它消失。需要注意的是，循环引用似乎是在文件之间，而不是简单的类型之间。因此，即使您的类型引用不是循环的，您可能仍然存在这个问题em取决于您的类型所在的.ts文件。@JoshuaKing您可以链接到有关该“限制”的资源吗cirtualr在typescript中导入类的情况？根据我的经验，导入的顺序也很重要。我有一个用户实体和两个具有相同抽象类的其他实体。其他两个实体也导入了用户，只要抽象类是最后一次导入（主要在用户之后）一切都很好。当我以另一种方式订购导入时，应用程序就坏了。@BrunoBieri这不是Typescript的限制。这是一个运行时错误-模块解析程序无法在循环导入中导航。我发现了一个很好的资源。那么，当您有索引文件（如你把基本文件放在哪里？或者索引文件有点反模式我不认为
index.ts
文件是反模式的，我知道有些人不同意这一点。我认为它们是为模块提供有用的公共接口的一种很好的方式。从内存中，我最终通过重构解决了这个问题，不需要导出一点也不象基类。不幸的是，我不能给你一个更好的答案。关于“落入陷阱”有一些奇怪的诗意在一篇关于循环引用的帖子中…：）谢谢，这太棒了！谢谢你分享这篇文章。奇怪的是，我没有找到循环依赖项！但这件事仍然抛出了同样的错误。虽然它不能解决我的问题，但如果不是因为这个，我会花很多时间寻找循环依赖项。我想为dpdm和Alternative说几句好话e到Madge。在我的代码中，Madge发现了1个无关紧要的循环依赖项，一点帮助都没有；另一方面，dpdm发现了27个实质性的循环路径。推荐。是的，当我没有正确地开玩笑时，我看到了这个错误-特别是，当通过
\uuuumocks\uuuuuu
模拟整个模块时，从那里使用的所有符号都需要是m锁定（或使用<代码取消锁定
madge --circular --extensions ts <directory_path>

madge --circular <directory_path>

// -- app.js --
import { AbstractNode } from './internal'

/* as is */

// -- internal.js --
export * from './AbstractNode'
export * from './Node'
export * from './Leaf'

// -- AbstractNode.js --
import { Node, Leaf } from './internal'

export class AbstractNode {
   /* as is */
}

// -- Node.js --
import { AbstractNode } from './internal'

export class Node extends AbstractNode {
   /* as is */
}

// -- Leaf.js --
import { AbstractNode } from './internal'

export class Leaf extends AbstractNode {
   /* as is */
}