Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ts-jest throws TypeError: Cannot read property 'version' of undefined #908

Open
thehappybug opened this issue Oct 18, 2020 · 4 comments
Open
Labels
scope: upstream Issue in upstream dependency solution: workaround available There is a workaround available for this issue

Comments

@thehappybug
Copy link

Current Behavior

npm run test fails to run with the error: "TypeError: Cannot read property 'version' of undefined"

npm run build, npm run lint and tsc --noemit run without errors.

image

This issue started happening randomly while I was working on some changes. I can't think of anything special that my project is doing, except that I have a linked dependency. Besides this project, I have other TSDX projects that are working fine.

Expected behavior

npm run test should work.

Suggested solution(s)

I haven't been able to solve this myself. This ts-jest issue (kulshekhar/ts-jest#1639) indicates a major version update is required.

Additional context

🤷‍♂️

Your environment

  System:
    OS: Windows 10 10.0.19041
    CPU: (8) x64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
    Memory: 7.06 GB / 15.85 GB
  Binaries:
    Node: 10.16.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.4 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 6.9.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 86.0.4240.75
    Edge: Spartan (44.19041.423.0), Chromium (86.0.622.43)
    Internet Explorer: 11.0.19041.1
  npmPackages:
    tsdx: ^0.14.1 => 0.14.1
    typescript: ^3.9.7 => 3.9.7
@agilgur5 agilgur5 added the scope: upstream Issue in upstream dependency label Oct 19, 2020
@thehappybug
Copy link
Author

A workaround is suggested here: kulshekhar/ts-jest#1645 (comment)

I ended up doing this:

  1. Turned on isolated modules.
  2. Updated test script in the package.json file to tsdx test --no-cache.

@agilgur5 agilgur5 added the solution: workaround available There is a workaround available for this issue label Oct 19, 2020
@agilgur5
Copy link
Collaborator

Yea, unfortunately since it's a breaking change upstream, TSDX can't update until its own breaking change. Jest 26 is slated for v0.16.0 since it requires a similarly breaking TS upgrade which requires some new and similarly breaking ESLint and Prettier versions. Also because v0.15.0 is focused on Rollup changes that will introduce enough changes as is.

The upstream issue suggests it's a cache issue, so maybe just clearing the cache or re-creating node_modules might fix it (temporarily).

I ended up doing this:

  1. Turned on isolated modules.
  2. Updated test script in the package.json file to tsdx test --no-cache.

To clarify for any other readers, the comment linked says that this is an OR condition, not an AND. Per the link, isolatedModules means less powerful type-checking, etc so something to generally avoid.

Could also use a resolution to upgrade at your own risk.

@agilgur5
Copy link
Collaborator

agilgur5 commented Nov 2, 2020

Just to be clear, for meaningful usage tsdx test is broken currently, and won't be fixed until v0.16.0?

@PurpleBooth that is a significant misrepresentation of the facts and is quite inaccurate. If that were the case then that would mean all of ts-jest 25.x is broken. But despite having millions of users, based on upstream and here, this is a super rare error that has only had 3 confirmed reproductions. Your issue #919 is also not the same issue as this. tsdx test has significant usage in the wild too and TSDX also dogfoods tsdx test and this issue does not occur in internal tests or in CI runs.
So it's inaccurate to say that "meaningful usage [...] is broken". It seems much more accurate to say there are some very rare cases where this error occurs.

I'll also mention that passive-aggressive comments are against the CoC. I'm not sure why you felt aggressive against and downvoted my factual comment. I did not state any opinions in my comment and I cannot control how upstream libraries make breaking changes... I have in fact made significant efforts to batch breaking changes so that TSDX users don't feel the impact as much -- I'm not exaggerating when I say there could be a breaking change every week otherwise. I've also spent probably a dozen hours or more reading upstream changelogs (some of which have few details, so I've had to read through commit logs and upstream PRs themselves, and some which leave out certain breakages, e.g. #727 (comment)) to make sure each dependency upgrade is done properly, since it's very easy to accidentally break one command by upgrading another or accidentally releasing something breaking in a non-breaking release (which has happened before).

This problem also has at least 3 different workarounds and likely more, as ts-jest itself can be turned off.

@PurpleBooth
Copy link

PurpleBooth commented Nov 2, 2020

Sorry, I was totally in the wrong here. I felt bad about posting that as soon as I did. I hope you accept my apologies.

Dobrokhvalov added a commit to DropListHQ/drop-protocol that referenced this issue Jan 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope: upstream Issue in upstream dependency solution: workaround available There is a workaround available for this issue
Projects
None yet
Development

No branches or pull requests

3 participants