错误报告
🔎检索词
ts获取JSX隐式导入库
获取JSX隐式导入库
ts文件.pragmas
🕗版本和回归信息
4.2.4
- 这是我尝试过的每个版本的行为，我查看了FAQ中关于所有内容的条目，但它没有被涵盖。
Playground链接
我不能提供一个操场的链接，因为这个问题似乎与仓库的结构和依赖关系有关。
我曾试图重现一个最小的例子，但目前还没有成功。
💻代码
这似乎与存储库的结构和依赖关系有关：
- 有2个单贮库-
core和product core中的一个软件包是toast- 在
product中有ui和services ui和services都依赖于toast，后者作为npmjs注册表中的外部依赖项安装在这两个系统中ui依赖于services
toast <-- external dependency (core monorepo)
| |
services | <-- product monorepo
\ |
ui <-- product monorepo在ui中，有一个Toast，它带有core中toast的自定义可视化实现，并带有自己的测试。
🙁实际行为
使用npx jest packages/ui/src/components/Toast/__tests__/Toast.spec.tsx运行测试时会崩溃，并显示：
TypeError: Cannot read property 'get' of undefined
at Object.getJSXImplicitImportBase (../../node_modules/typescript/lib/typescript.js:19175:95)
at transformSourceFile (../../node_modules/typescript/lib/typescript.js:88624:51)
at transformSourceFileOrBundle (../../node_modules/typescript/lib/typescript.js:82540:57)
at transformation (../../node_modules/typescript/lib/typescript.js:100190:24)
at transformRoot (../../node_modules/typescript/lib/typescript.js:100217:82)
at Object.transformNodes (../../node_modules/typescript/lib/typescript.js:100201:78)
at emitJsFileOrBundle (../../node_modules/typescript/lib/typescript.js:100852:32)
at emitSourceFileOrBundle (../../node_modules/typescript/lib/typescript.js:100799:13)
at forEachEmittedFile (../../node_modules/typescript/lib/typescript.js:100520:34)
at Object.emitFiles (../../node_modules/typescript/lib/typescript.js:100779:9)在检查问题时，我注意到以下行为：
- 导致崩溃的文件是
packages/ui/node_modules/@private/core-toast/src/index.ts - 此文件的
SourceFileObject缺少pragmasMap - 但它包含
redirectInfo与redirectTarget：packages/ui/node_modules/@private/product-services/node_modules/@private/core-toast/src/index.ts个 - 此
redirectInfo中的SourceFileObject包含pragmasMap
这发生在本地开发以及travis CI中。
🙂预期行为
jest测试运行时不会崩溃。
可能相关问题
#43373的最大值
4条答案
按热度按时间u1ehiz5o1#
嗯，没有一个repro是很难验证的，但是我 * 认为 * 问题在于
ts-jest使用我们的转换API和一个preTransform，我们的工厂没有保留信息....也许。事实上，看过ts-jest的源代码，我完全相信，考虑到他们如何实现他们的访问者-通过使用对象传播而不是我们的工厂API，您可以尝试查看此构建是否有帮助，但由于ts-build不使用我们的工厂来制造节点，因此我认为它不会有帮助。如果您可以在ts-jest安装中找到this transform和this transform，并修改它们，使每个跨页都像Object.setPrototypeOf({ ... }, Object.getPrototypeOf(original))一样被 Package ，这样就修复了崩溃，而更改为ts-jest可能是解决方案。Ofc，这只是因为我们内部的
RedirectedFile构造依赖于原型继承来实现功能，这使得维护原型成为一个转换器的安静需求......ryevplcw2#
抱歉现在又说这个。我被其他工作耽搁了。
我试过那个特定的建筑，但没有运气。
我已经在node_modules内的js文件中找到了这两个转换。但是，我还没有设法通过 Package 这些扩展来修复它。出于好奇，我试图设置pragma，如果它是从
redirectTarget中未定义的，它会崩溃，因为text在computeLineStarts中未定义，所以我觉得你的想法是正确的。我应该在ts-jest中打开一个问题，还是你想这样做，因为你知道更多关于细节？
x7yiwoj43#
嗯，没有一个repro是很难验证的，但是我 * 认为 * 问题在于
ts-jest使用我们的转换API和一个preTransform，我们的工厂没有保留信息....也许。事实上，看过ts-jest的源代码，我完全相信，考虑到他们如何实现他们的访问者-通过使用对象传播而不是我们的工厂API，您可以尝试查看此构建是否有帮助，但由于ts-build不使用我们的工厂来制造节点，因此我认为它不会有帮助。如果您可以在ts-jest安装中找到this transform和this transform，并修改它们，使每个跨页都像Object.setPrototypeOf({ ... }, Object.getPrototypeOf(original))一样被 Package ，这样就修复了崩溃，而更改为ts-jest可能是解决方案。Ofc，这只是因为我们内部的
RedirectedFile构造依赖于原型继承来实现功能，这使得维护原型成为一个转换器的安静需求......嗨，我想迁移到工厂API应该是正确的方向？
nfg76nw04#
我想这样就能解决问题了。