Simen Bekkhus comments

Results 1232 comments of


                                            Simen Bekkhus

`tracing::instrument` triggers `blocks_in_conditions`

Still happens in my project using 1.80. as well. However, looking at the changelog, only commits up until May 30th were included, and the fix for this landed June 8th....

`@opentelemetry/otlp-exporter-base` TS error in Node environment

We've had this issue in Jest as well. If some dependency, somewhere in the monorepo, has a `/// references lib="dom"` (or whatever the syntax is) somewhere, or its `@types/*` does,...

`@opentelemetry/otlp-exporter-base` TS error in Node environment

In our case it was `@types/jsdom` which pulled in `dom`. Solution was to make `jsdom` optional 😅 AFAIK there's not a more general solution

[expect-expect] Option to enforce the last statement of a test to be an assertion

@G-Rath thoughts on this? I think it sounds like a good idea - not sure if it should be an option on `expect-expect` or a separate rule

chore: do not use resolutions for typescript dependency

I'm guessing this is something deep inside ts-eslint…

chore: do not use resolutions for typescript dependency

#1525

Ensure expect(function).toThrow()

You get a runtime error (and possibly a type error?) for this already. Not sure if a lint rule is needed?

Feature Request: Make this plugin work with bun

I don't wanna hard code in `bun` stuff, but happy to take a PR that makes `@jest/globals` as import source configurable. A caveat is that there's no guarantee the semantics...

Feature Request: Make this plugin work with bun

I have no interest in maintaining a comparison table (or changing default behaviour). But an option to allow people to mix and match seems fine as long as we state...

Prefer jest.MockedFunction<T> over jest.Mock

I'm not sure if we should get involved with recommendations for `@types/jest`. Very much open to being convinced otherwise, tho. @G-Rath @jeysal @thymikee thoughts?