Mateusz Burzyński

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?

www.typescriptlang.org/play/?ts=5.9...

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 😬

Don't suggest private fields in contexts where they are out of scope · Issue #56177 · microsoft/TypeScript 🔎 Search Terms private fields suggestions 🕗 Version & Regression Information This is the behavior in every version I tried, and I reviewed the FAQ for entries about private fields ⏯ Playground Link...

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...

Enable `--strict` by default · Issue #62333 · microsoft/TypeScript Background Almost a decade ago, we began to add certain options beyond --noImplicitAny and --strictNullChecks. Flags like --strictFunctionTypes, --noImplicitThis, and --strictBindCallApply have bee...

Yesssss 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

github.com/replayio/rep...

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

a man in a hot dog costume has the word wrong on the bottom right ALT: a man in a hot dog costume has the word wrong on the bottom right

Wrong!

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? (: