Comments (9)
@Rugvip, the fix to this should now be released as part of 6.4.2 👀 Can you check on your end? :)
from jest-dom.
@fpapado Thank you for the reply! 🎉
- Yes, if I switch it to just
type ByRoleMatcher = ARIARole | (string & {})
I no longer see any errors.
I played around with the types a bit in this repo. I didn't find any instructions for how to check types, but I've been running npm exec tsc
. Something seems strange with the setup in this repo. If I for example add something obviously broken like export 'bad'
at the end of matchers.d.ts
, I get an error. But even something like switching export = matchers
to export = nonexistent
doesn't break the type checking.
I moved over to reproducing in a minimal Backstage setup instead:
npx @backstage/create-app@latest --skip-install # "repro-jest-dom" as app name
cd repro-jest-dom
yarn install
yarn tsc:full # error
In that setup I could verify that removing the ByRoleMatcher
export at least make those type checks happy.
from jest-dom.
@fpapado yep those do catch the export = notAThing
, but as far as I can tell it's because the matchers are of the things explicitly tested. If you for example add type non = existent
at the bottom that's not caught.
from jest-dom.
Aha! I believe it is "skipLibCheck": true
in the root tsconfig.json that is causing these errors to be silently ignored.
skipLibCheck
skips checking all .d.ts
files, unless specifically referenced by the source code. This explains the discrepancy that we are seeing between tests and running tsc
directly 💡
By switching it off, or by running tsc directly on the types/matchers.d.ts
file (i.e. bypassing tsconfig.json
), the original error shows up, without the changes in #575.
However, when changing this, there is a cascade of other errors that show up. I do not know which ones are valid, because the type overloading / declaration merging in this library seems complex. This leads me to think that skipLibCheck
is somehow load-bearing for the type setup here, but at least this gives a way to verify the changes!
Incidentally, at work, we also have "skipLibCheck": true
, which would explain why I could not reproduce this originally.
CleanShot.2024-01-31.at.08.57.58.mp4
from jest-dom.
I tried it in our setup, and the fix works. Thank you!
from jest-dom.
Works for us too, thank you! 👍
from jest-dom.
Hi @Rugvip! I am not a maintainer, but I am the person that contributed .toHaveRole
, so I take some of the responsibility 😌 First of all, my apologies for the hassle!
Two quick checks
Can I ask you to check two things on your end?
- If you modify
matchers.d.ts
to remove theexport
declaration forByRoleMatcher
, are the type errors fixed? - If not, can you check removing the
import
andexport
forByRoleMatcher
, and changing this line torole: string
?
Since the core export of the package is the matchers, there is no need to separately export the ByRoleMatcher
anyway. We just want the argument to .toHaveRole
to be well-typed (the full type of the matcher can be extracted with Parameters
/ReturnType
and co if need be, I suppose) So option 1 might be a simple way to thread the needle, and a follow-up PR :)
You can use patch-package, pnpm's native patching, or even the code editor in a pinch, whichever you prefer.
I ask you, because I tried to reproduce this issue in our codebase at work, and we are not getting this issue. Tests type-check both with and without the change in option 1 above. TypeScript config is vast, so I'm not drawing any conclusions yet 😅
Some more context on the fixes
Might be enough to switch the re-export to
export { matchers }
?
This would probably not be enough. For example, the type tests in this repository fail with that change.
You can run the type tests in the repository via npm run test:types
. The type tests themselves are in the types/tests directory.
I tried copying over your tsconfig.json
into that tests folder, and the tests seemed to still pass. At a glance, I don't see anything in the config that could cause this, so I suspect some other underlying cause.
Future testing
I have a gut feeling that the type tests in this repository are missing some use-cases (perhaps config combinations), if they can break like this. I don't have a concrete suggestion for it right now; maybe the maintainers have run into this before?
from jest-dom.
Thanks for checking, @Rugvip!
I opened a PR for the maintainers to consider, but I do not have a good test case to add to the repo. So I leave it up to them, how to proceed. I opened the PR mostly to account for any timezone differences, not because it is the end-all-be-all solution :)
But even something like switching export = matchers to export = nonexistent doesn't break the type checking.
Did you try running the type tests with npm run test:types
? There's different tsconfig projects under types
, so they are run individually, via that script. When I do that with a nonsensical export = notAThing
, they seem to error as intended:
CleanShot.2024-01-30.at.21.10.03.mp4
from jest-dom.
FYI, using skipLibCheck will cause type-errors to silently result in any
types, so it's not a good idea to set this unless you really really need to.
from jest-dom.
Related Issues (20)
- Checking if input value is empty string using toHaveValue
- Property 'toBeInTheDocument' does not exist on type 'JestMatchers<HTMLElement>' HOT 24
- Support assertions for each DOM query HOT 8
- toHaveStyle fails on custom property names containing uppercase letters HOT 4
- TypeScript types for the `"./matchers"` export don't match implementations HOT 3
- Regex support for `.toHaveClass()` HOT 9
- toBeVisible is not seeing svelte-kit classes HOT 1
- `"types": ["jest", "@testing-library/jest-dom"]` not working after v6 upgrade HOT 3
- .toHaveAttribute('disabled') and .toBeDisabled() HOT 1
- toHaveStyle does not behave consistently between number and string values HOT 10
- toHaveStyle for property `font-size` behaves incorrectly for number values HOT 2
- Does not work with vitest 1.x.x HOT 10
- `.toHaveStyle()` doesn't know about aspect-ratio HOT 6
- Property 'toBeInTheDocument, toBeDisabled, etc' does not exist on type 'JestMatchers<HTMLElement>' HOT 4
- Remove unused and deprecated package `jest-environment-jsdom-sixteen`
- [attribute selector]:has(+ el) pseudo-class selector with emotionStyled reported as syntax error
- Memory leak when importing @testing-library/jest-dom in jest-setup file with NodeJS 20
- Cost effective lodash HOT 2
- toHaveStyles always report hover style HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jest-dom.