It might be an extra hidden “feature” but u can actually record node scripts with the Replay’s node recorder - it’s more experimental and stuck on node 16 (🥲) but that’s often enough
I cant even stress enough how helpful (and basically essential!) it’s for my @typescriptlang.org contributions. I feel im flying through some problems with it. It wont magically allow me to fix everything, duh, but diagnosing things with it is a breeeeze
That’s how we, Polish people, smile
I thought about a pretty aggressive lint that would force u to use a getter for values assigned to from inner callbacks
Its tradeoff, a flag increases bugs surface - i doubt it would be worth having it. Maybe write an eslint rule helping u to catch such issues?
this is literally just #9998, the fact the async function is involved is kind of a red herring here.
u should try to use the builtin one when possible, u can leverage typesVersions to route your types depending on the compiler version - but tbh, it tends to be slightly complicated at times
if it would be able to do that then most likely it would just simplify this whole type eagerly. TS is pretty smart about such simplifications: what u write !== what u get:
type Test<T> = [T][0]; // type Test<T> = T
conditional types are deferred on purpose and, in here, it wont be able to simplify this indexed tuple to uncover what's the actual contained type there when it checks that assignment
Internal implementation is internal - it's not something u can express 1to1 in userland, its behavior is encoded in the compiler's code.
Out of curiosity - what’s your use case?
A hacky way could be to inject a global fixture but then only run its body once? It would be a process-level once though (most likely)
Have you missed the memo? I feel like people are doing this all the time - giving me anxiety 😬
If u’d make ur class nominal with private properties then it still wouldnt work but ur issue would become a duplicate of github.com/microsoft/Ty...
Its disputable what would be correct here - but i’d appreciate if all 3 of those would at least behave in the same way given they ultimately do exactly the same thing
Guilty as charged, that was my PR ;p
So u cant even do smth like
(params) => {
const { page } = params:
}
This wont match their regex ;p
Hm, im not sure if this applies to test functions but they parse fixture functions and literally look for the destructured argument in the source text of the function to learn what other fixtures are used by it - then, i imagine, they create the dependency tree (and init them in order) based on that
Yes, emphasis is on all tests - we need to add extra instrumentation in tests and u cant do that from a reporter, we need to run code in the context of the test code. But we dont want to force users to import our instrumented fixture - they should continue using standard test import
We found a hacky way to inject a custom fixture that runs for all tests so i can do some custom stuff before and after the use() call. Dont tell the Playwright team
This is cool
It’s spooky… and boils down to the above inconsistencies with never - that generic has a base constraint of never
What truly prompted this was the situation from our codebase that i narrowed down to www.typescriptlang.org/play/?ts=5.9...
That is correct! This is quite weird from the consistency’s standpoint 😢 i could even live with all of them not being errors, which could be a fair answer given `acceptString(accidentalNever)` is not an error and i dont imagine it being one
But i know where u are coming from :p
![declare const test: never;
if ("foo" in test) {
}
test.foo;
test["foo"];
const { foo } = test;](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:vuffylqbkratb2z65hsvrat3/bafkreibrwvviyd34tu6ehscclnbo34aonkeujrqazwwfs2la3slq4ofaqe)
declare const test: never; if ("foo" in test) { } test.foo; test["foo"]; const { foo } = test;
Trivia question - how many errors are reported by TS here? (:
