chore(deps): update dependency typescript to v6

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
typescript (source)	5.9.3 → 6.0.2

---

Release Notes

microsoft/TypeScript (typescript)

v6.0.2

Compare Source

---

Configuration

📅 Schedule: Branch creation - Between 12:00 AM and 03:59 AM, on day 1 of the month ( * 0-3 1 * * ) (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[netlify]

✅ Deploy Preview for fakerjs ready!

Name	Link
🔨 Latest commit	f918042
🔍 Latest deploy log	https://app.netlify.com/projects/fakerjs/deploys/69cf67af1329de0008b422a1
😎 Deploy Preview	https://deploy-preview-3772.fakerjs.dev
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[Shinigami92]

This is blocked by egoist/tsup#1388
And can be unblocked by merging #3558

- egoist/tsup#1388
- #3558

Now there are some TS errors, will check them later

claude wants to remove the const from

faker/src/modules/helpers/index.ts

Line 767 in 3565626

maybe<const TResult>(

and

faker/src/modules/helpers/index.ts

Line 1077 in 3565626

multiple<const TResult>(

so that e.g. this

faker/test/modules/helpers.spec-d.ts

Line 50 in fa19801

expectTypeOf(actual).toEqualTypeOf<number | undefined>();

test succeeds

somehow this feels wrong to me

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.88%. Comparing base (ed36f5c) to head (f918042).

Additional details and impacted files

@@           Coverage Diff           @@
##             next    #3772   +/-   ##
=======================================
  Coverage   98.88%   98.88%           
=======================================
  Files         886      886           
  Lines        3061     3061           
  Branches      556      556           
=======================================
  Hits         3027     3027           
  Misses         30       30           
  Partials        4        4           

Files with missing lines	Coverage Δ
src/modules/helpers/index.ts	95.28% <100.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Shinigami92]

downlevelIteration and target=ES5 in cypress not supported by TS6 anymore 🙄

faker/cypress/tsconfig.json

Line 3 in 819105b

"target": "ES5",

enough for today

[Shinigami92]

maybe we should switch to playwright 👀

[xDivisionByZerox]

maybe we should switch to playwright 👀

If I remember correctly - playwrite is owned by microslop.

I know that is not a strong statement when I'm writing a comment in Github on my Windows machine using VSCode to maintain this project while chatting with Copilot, BUUUUUUUT it still an argument xD

[Shinigami92]

maybe we should switch to playwright 👀

If I remember correctly - playwrite is owned by microslop.

I know that is not a strong statement when I'm writing a comment in Github on my Windows machine using VSCode to maintain this project while chatting with Copilot, BUUUUUUUT it still an argument xD

TBH, this is not "an argument" but reads more like personal preferences.
I like some MS products and like you say I also settled in some of their infrastructure like GitHub and VSCode.

I have some experience with Playwright and Cypress, and for me it felt like an X-Graph one day, where Cypress treated its community poorly and imposed some strange quirks, while Playwright feels more natural and native to the TypeScript ecosystem, especially with its async-await syntax. Also Playwright at least feels a bit faster, but I don't have benchmarks for that, so this might also just be personal preference.

I will now go checkout if the webpack preprocessor is still necessary or if that was just something weird.

[Shinigami92]

I will now go checkout if the webpack preprocessor is still necessary or if that was just something weird.

Yes, indeed, I'm not 💯% sure what's going on, but the preprocessor is invoked and without it it does not work 😕

I could have a look later if switching to Playwright would result in any benefits as an experiment.

The other thing in this PR is the removal of const for some generics. Maybe I could kindly ask @ST-DDT to have a deeper look into that, because as far as I remember he had the nearest experience with implementing them when we introduced them.

[ST-DDT]

We used them to express the following:

arrayElement(['foo','bar']): 'foo' | 'bar'
VS
arrayElement(['foo','bar']): string

For factory functions (maybe/multiple) this didnt really work like expected.

faker/test/modules/helpers.spec-d.ts

Lines 47 to 57 in ed36f5c

	describe('maybe', () => {
	it('generic single element', () => {
	const actual = faker.helpers.maybe(() => 1);
	expectTypeOf(actual).toEqualTypeOf<number | undefined>();
	});
	it('const generic single element', () => {
	const actual = faker.helpers.maybe(() => 1 as const);
	expectTypeOf(actual).toEqualTypeOf<1 | undefined>();
	});
	});

[Shinigami92]

We used them to express the following:

arrayElement(['foo','bar']): 'foo' | 'bar' VS arrayElement(['foo','bar']): string

For factory functions (maybe/multiple) this didnt really work like expected.

faker/test/modules/helpers.spec-d.ts

Lines 47 to 57 in ed36f5c

	describe('maybe', () => {
	it('generic single element', () => {
	const actual = faker.helpers.maybe(() => 1);
	expectTypeOf(actual).toEqualTypeOf<number | undefined>();
	});
	it('const generic single element', () => {
	const actual = faker.helpers.maybe(() => 1 as const);
	expectTypeOf(actual).toEqualTypeOf<1 | undefined>();
	});
	});

Ah thanks for the context
So now TS6 has some changes to their type IDs (https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/#the---stabletypeordering-flag), I assume it has something to do with that

when I bring back the const, I get these errors

Details

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Failed Tests 3 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

 FAIL  test/modules/helpers.spec-d.ts > helpers > maybe > generic single element
TypeCheckError: Type 'number | undefined' does not satisfy the constraint '"Expected number, Actual never" | "Expected undefined, Actual never"'.
  Type 'undefined' is not assignable to type '"Expected number, Actual never" | "Expected undefined, Actual never"'.
 ❯ test/modules/helpers.spec-d.ts:50:42
     48|     it('generic single element', () => {
     49|       const actual = faker.helpers.maybe(() => 1);
     50|       expectTypeOf(actual).toEqualTypeOf<number | undefined>();
       |                                          ^
     51|     });
     52|

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/3]⎯

 FAIL  test/modules/helpers.spec-d.ts > helpers > multiple > const generic single element
TypeCheckError: Type 'number[]' does not satisfy the constraint '"Expected number, Actual never"[]'.
  Type 'number' is not assignable to type '"Expected number, Actual never"'.
 ❯ test/modules/helpers.spec-d.ts:123:42
    121|     it('const generic single element', () => {
    122|       const actual = faker.helpers.multiple(() => 1);
    123|       expectTypeOf(actual).toEqualTypeOf<number[]>();
       |                                          ^
    124|     });
    125|

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[2/3]⎯

 FAIL  test/modules/helpers.spec-d.ts > helpers > multiple > const generic multiple elements
TypeCheckError: Type 'number[]' does not satisfy the constraint '"Expected number, Actual never"[]'.
  Type 'number' is not assignable to type '"Expected number, Actual never"'.
 ❯ test/modules/helpers.spec-d.ts:128:42
    126|     it('const generic multiple elements', () => {
    127|       const actual = faker.helpers.multiple(() => 1, { count: 3 });
    128|       expectTypeOf(actual).toEqualTypeOf<number[]>();
       |                                          ^
    129|     });
    130|   });

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[3/3]⎯

however, I think these nevers are bad, are they?

[ST-DDT]

So now TS6 has some changes to their type IDs (https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/#the---stabletypeordering-flag), I assume it has something to do with that

The text doesnt mention that at all AFAICT.

however, I think these nevers are bad, are they?

Yes, they are. It being detected as never feels like a bug to me.
Since removeing const does not break the tests I dont mind their removal.
We should verify with the playground that the resulting types dont change though.

Faker TS5/6 × Playground TS 5/6

If Faker TS5 in a TS6 playground causes the same issues as in the tests here then maybe we should consider splitting the const removal into a different fix PR for better visibility in the changelog.

We should add a playground/test that explicitly tests TS5 downstream compatibility though (at least for some of the generic stuff).

[Shinigami92]

[...] I assume it has something to do with that

The text doesnt mention that at all AFAICT.

That's why I wrote "assume"

however, I think these nevers are bad, are they?

Yes, they are. It being detected as never feels like a bug to me. Since removeing const does not break the tests I dont mind their removal. We should verify with the playground that the resulting types dont change though.

Faker TS5/6 × Playground TS 5/6

If Faker TS5 in a TS6 playground causes the same issues as in the tests here then maybe we should consider splitting the const removal into a different fix PR for better visibility in the changelog.

We should add a playground/test that explicitly tests TS5 downstream compatibility though (at least for some of the generic stuff).

I think you are right with all of that
I will first check if the removal of const changes the behavior of <=TS5.9, then I will have a look into the playgrounds
But not sure if I will do this today or just somewhere in the long weekend
Maybe it is even a TS6 bug which just has a really small usage coverage in the TS community and MS 🦆 up

[ST-DDT]

Maybe we should delay this to v11 as a potentially "breaking change".