Open salik1992 opened 3 years ago
Hm, this is difficult to verify without a repro, but I think the problem lies in ts-jest
using our transformation API with a preTransform and our factory not retaining information.... maybe. In fact, looking over ts-jest
's source code, I fully believe that, given how they implement their visitors - by using object spread and not our factory API, they're un-setting node prototypes. You can try to see if this build helps, but since ts-build
doesn't use our factory to manufacture the nodes, I don't think it'll help. If you can locate this transform and this transform in your install of ts-jest
, and modify them so that every spread is wrapped like Object.setPrototypeOf({ ... }, Object.getPrototypeOf(original))
, and that fixes the crash, that change to ts-jest
may be the solution.
Ofc, this is only the case because our internal RedirectedFile
construct relies on prototypical inheritance to function, which makes maintaining prototypes a quiet requirement of a transformer...
Sorry for getting back to this now. I was blocked by some other work.
I have tried that specific build but no luck.
I have found those two transforms in generated js files inside node_modules. However, I haven't managed to fix it by wrapping those spreads. Just out of curiosity I have tried to set pragmas if it was undefined from that redirectTarget
and it crashes further down the line on text
being undefined in computeLineStarts
so I feel like your belief is correct.
Should I open an issue in ts-jest or do you want to do it since you know a lot more about the specifics?
Hm, this is difficult to verify without a repro, but I think the problem lies in
ts-jest
using our transformation API with a preTransform and our factory not retaining information.... maybe. In fact, looking overts-jest
's source code, I fully believe that, given how they implement their visitors - by using object spread and not our factory API, they're un-setting node prototypes. You can try to see if this build helps, but sincets-build
doesn't use our factory to manufacture the nodes, I don't think it'll help. If you can locate this transform and this transform in your install ofts-jest
, and modify them so that every spread is wrapped likeObject.setPrototypeOf({ ... }, Object.getPrototypeOf(original))
, and that fixes the crash, that change tots-jest
may be the solution.Ofc, this is only the case because our internal
RedirectedFile
construct relies on prototypical inheritance to function, which makes maintaining prototypes a quiet requirement of a transformer...
Hi, I guess migrating to factory API should be the right direction?
That's what I'd assume would fix the issue, yeah.
Bug Report
🔎 Search Terms
ts getJSXImplicitImportBase ts jest getJSXImplicitImportBase ts file.pragmas
🕗 Version & Regression Information
4.2.4
⏯ Playground Link
I can't provide a link to a playground as this issue seems to be tied to the structure of the repository and dependencies. I have tried to reproduce a minimal example but without luck for now.
💻 Code
This seems to be tied to the structure of the repository and dependencies:
core
andproduct
core
istoast
product
there areui
andservices
ui
andservices
are dependent ontoast
which is installed as an external dependency from npmjs registry in both of themui
is dependent onservices
In
ui
there is aToast
with custom visual implementations for thetoast
fromcore
with its own tests.🙁 Actual behavior
Running tests with
npx jest packages/ui/src/components/Toast/__tests__/Toast.spec.tsx
crashes with:when inspecting the issue I have noticed this behaviour:
packages/ui/node_modules/@private/core-toast/src/index.ts
SourceFileObject
of this file is missingpragmas
mapredirectInfo
withredirectTarget
:packages/ui/node_modules/@private/product-services/node_modules/@private/core-toast/src/index.ts
SourceFileObject
from thisredirectInfo
containspragmas
mapThis happens during local development as well as in travis CI.
🙂 Expected behavior
The jest tests run without crashing.
Maybe related issue
#43373