type-fest known bugs

### Bug description ```tsx interface User { name: string; surname?: string; readonly id: number; } type _User = WritableKeysOf<User>; // return "name" | "surname" | undefined const user: _User = undefined; // not error ``` ### Repro https://www.typescriptlang.org/play/?#code/PTDECcFMHMEsHsB2ACALgTwA6QLQDNIBnVAWAChyNtkBJQgUQEcBXAQwBsAeAQQBpkAQgD5kAXnIBIABScA4kKkBKMSNnJIAD1SREAE0LJuyAGTI1AHzPIA-MgCMyAFzIATMs3a9hSTPlKVVh46+oImVpZqtg7ObpK2qODMkJLOeByEkADc5JRYkMgA6uCwqKwARuyQANKQ6IQA8nicACoiosgAckgdzOzs5ZWcAN6SANoACsiwKADWtfB4yM0Aus50TGxcQ8ijAIpTKOOrSxPLyAC+-NtQrLpI7Og7+9PIR87NpxciQV7IaewZGyvJzIRCQABukHA5HOozm6AWS2WQmyFDIIFAwSgcCQOTI0204DSAGN8gBVDLgZAjMgSRCsAC2kGcxGKiGgqIkhGY4HpTOsLIS0w5khud0QDymumciGYDLKUNR51y1AA+hSoWJCsVShVqrUGk0NeAUcgQMgoKgeShkAAiPmQW3ISy27m8xmO53IZh6SB4aaQXTkYlIYjeynOdWUrU+3R+gO6TJm4Cg+CodTgcDwcBAA

### Bug description Hi everyone, The attached code snippet worked with version 4.37.0 and TSConfig `strictNullChecks=false`. It errors in version 4.38.0; from the error message it would seem like `recurseIntoArrays: true` is not applied, so I guess `ApplyDefaultOptions` does not have the intended behavior with `strictNullChecks=false`. While the recommended usage of `type-fest` is with `--strict`, this is a regression for existing codebases, and the impact should be evaluated since `ApplyDefaultOptions` is widely used in 4.38 Thanks everyone! ### Repro https://www.typescriptlang.org/play/?strict=false&strictNullChecks=false&strictFunctionTypes=false#code/JYWwDg9gTgLgBDAnmApnA3gBQIa2NgGwBEUUwBfOAMyghDgHIlUBaKlAZxgYG4BYAFCDgAOxgooVbAGM0AZVBgCKAPIAjAFYpp8dIICQI7CBQAuOFyiiA5vwHlBwsRKmy4AYTpKUAD3VadDAMjE3NLGwAaOAMCYC4AfnMFcGV-bRgAbQBdQQchAWY0EEQcPEIAFWQ0AF44Uph8YlIwAB5PFN80nSj0KG0AVygOFABJMQgAQSgobEQOcxgofpRyAD5HAWkCbA4OOGL3bd24RWUTMT3i+sbK1CCBQ2MURItFmzt9WITza8ISMhayW8XRgPT60kGwzGMEm01m8wQSxWq2ycGi9iAA

### Bug description I have this type to pick all optional keys and make them required. After update (v4.39.0) i seem to get the error `Type 'string' is not assignable to type 'never'` ```ts type PickAndRequireOptionalKeysOf<T extends object> = { [K in keyof Pick<T, OptionalKeysOf<T>>]-?: T[K] } ``` In the playground i also added the old `OptionalKeysOf` as `OptionalKeysOfOld`. When i use that my type works just as intended. I'm not sure if this is a bug or unintended usage on my side. ### Repro https://www.typescriptlang.org/play/?#code/C4TwDgpgBAqgdgSwPZwCpIJJ2BATgZwgGNhk4AeeMgPigF4oAKAKAEgqUoIAPHOAE3xQArnADWcJAHc4bVgH4m-BPmC4EAI2E5+HOAC5YiFAEp6tAG5IE-OYbgQLeZmZ59BTRgFs8Acwj8WDgExKQohghwAGZ4UEF4hCRkZnSW1vwmbIrxIUmcAGRGZGz2jngA3MzMoJBQANIQIPgA8lF65M0aAFahqOAQtHTMUFBijUhRRSjoOYlhFJ09JH21bhACQqIS0nBQigBKxEi4-ORjIBNQi739ADRQDk64tKVP1JXV-Vdg8wCGADYNJqtcgAIV+hBW0DWGygSG6oUG9UaLTaxgoAG82ABtIFQSKjcaTcGQr4QqAkiBQri8dYeQ5EY6nIH3SlQ3GNAC6tEUj1ihiBnNezgAvu8qp9as0fmQAUDUc1-qc2V8YR54UtgEiAKLcIj-YT8CDkYYjKBYs2WqAckD43bnS4qyBCikQqmq2mwhlM8gs12kyA27l7B5lXBQAWNU0jEXYh3Et1Qzm3aMiAQQKKRALMagSmrQAAKCCIYgAggJDgBHYQIXAQaV-QEokGoGnuIQaxH0c2p3F2wkXSZFkvkVD3BuypvAqKj6jUTkAWnkhlQuM5zBFVXzUAAYkgkN2LWa69XawEAPoaX64QyqdRwXyppAylAAy-X5dQO+RR+byXQKsazrfgJ1ff49wPBhhzLCsIFPOtQLgOVmxnCDqCAA

### Bug description If `PartialDeep` is given an object with a call signature, it doesn't seem to make other properties on that object optional. ```ts import { PartialDeep } from "type-fest"; interface CallableWithProperty { (): string; example: number; } type Result = PartialDeep<CallableWithProperty>; let result: Result; result = () => ""; // Property 'example' is missing in type '() => string' but required in type 'CallableWithProperty'. ``` This feels like a bug? ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAbzgBQIa2KgNgEQKZ5hwC+cAZlBCHAEQwCeYeAtGXgM4w0DcAsAFADgAOxh4oZVAGM8cAMLYsqAEZY8AdWAwAFskpNY9RALhwAFAEoAXHE5QRAcz79TeAB6pwam8ICuIZXFnYgEBBiY4ACUOXyx4AF4UdBhMXAIwAB4FLCVVDS1dfXEGAD5nATV4KBi4m2j2WJhy-mqGuLhEyw6S2h4gA

### Bug description ```ts import type {CamelCasedPropertiesDeep,SnakeCasedPropertiesDeep} from 'type-fest'; type Foo = { x: unknown; }; type CamelCased = CamelCasedPropertiesDeep<Foo>; type SnakeCased = SnakeCasedPropertiesDeep<Foo>; ``` Expected: ```ts type CamelCased = { x: unknown; }; type SnakeCased = { x: unknown; }; ``` Actual: ```ts type CamelCased = { x: {}; }; type SnakeCased = { x: {}; }; ``` ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBDAnmApnA3gYQIYhQGxwGcUATABSglVmBSIBEUUwAaAZQDtsBrFYspWopa9JiwC+cAGZUQcAORJUAWmn0YCgNwBYAFD7laAGIQIcALwZ9ASAAeALjgBXTj04QA7p116Jvw2Q0HDxCbBJSSzgQggEKKhoYOkZmMAAeUwgAPl84PLgAegK4AD0Afn1A1DguXn5wsijavjihROTxdMyc-XzC4vL9IA

### Bug description I'm trying to build a type that is the following: `"01" | "02" | "03" | "04" | "05" | "06" | "07" | "08" | "09" | "10" | "11" | "12" | "13" | "14" | "15"`. Basically, this is a string representation of the numbers 1 to 15, but the number should have a leading `0` if it is less than `10`. I have made these types: ```ts type NumberRange = IntClosedRange<1, 15>; type LeadingZero<N extends number> = LessThan<N, 10> extends true ? `0${N}` : `${N}`; ``` This works fine when it takes a single number as input, but fails when used with a union of multiple numbers. ```ts type A = LeadingZero<1>; // "01" (Correct) type B = LeadingZero<10>; // "10" (Correct) type C = LeadingZero<1 | 10>; // "01" | "010" (Incorrect, should be "01" | "10") type D = LeadingZero<NumberRange>; // "01" ... "015" (Incorrect) ``` ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBDAnmApnA3nAkgOxgYQBsIBnFAEwCUBDHAcxQBo4AZFEkgFQAta4BfOADMoEEHADkSVAFoh7GBIDcAWABQ66WgByAVxAAjFFBr00AXmx4ipCqYYAeAIzMnAVgB8qtVtYpq5MD0AFrGEA7acCgAHjAoOOQkcDj6RlAecJZsHDy0Ea4ADBkxcQlJMFC6aAD8cAAGBQAk6Nr8dXAAXPXNrXXe6prIaACCmX4BQXShos5ecAD083AARAVOy4OocABCY2wTIWHORUoLS8tOBRs+Q3D4e-6BhzNOcAA+cJdziytry++-S7XXwAEQeBymRz0hmM9hQ33OfzgADpUYCACzXIA

### Bug description Given ```typescript type Foo = { foo: string } type Bar = { bar: string } type FooBar = Foo | Bar ``` I would expect `Pick<FooBar, "foo">` to behave the same as `PickDeep<FooBar, "foo">`, since it's not really going deep. The first case fails with `Type '"foo"' does not satisfy the constraint 'never'.`, but the second resolves to `{ foo: string }`. Which seems very wrong to me, as `Bar` values don't have a `foo` field. ### Repro https://www.typescriptlang.org/play/?ts=5.8.3#code/JYWwDg9gTgLgBAbwArAMYGsAiBTbYC+cAZlBCHAOQwCeY2AtEdgM4wUDcAUJzXXAGIQIcALyJOcYkIBccVlGAA7AOad83XtjgAhAIZRR4yQCN9s+UtXqetLYIh6DY+3AA+O-RttwAKixgoGIaB6AA89o4ANHAARERCMQB8XJq+-iE4eMFoWLhg4UJRsfEQSUA

### Bug description Given the following code ```typescript import { SingleKeyObject } from 'type-fest'; const OPERATORS = ['$eq', '$ne', '$in', '$notIn'] as const; type Operator = (typeof OPERATORS)[number]; type Rule = Record<Operator, string | string[]>; type SingleKeyRule = SingleKeyObject<Rule>; ``` `SingleKeyRule` always evaluates to "never" <img width="684" alt="Image" src="https://github.com/user-attachments/assets/173c2309-d2c5-40ef-8b65-be1d26216bc9" /> I expected it to evaluate to something different, but if we try ```typescript const rule: SingleKeyRule = { $eq: 'something' } ``` we get ``` Type '{ $eq: string; }' is not assignable to type 'never'. ``` and it makes this type basically unusable 😢 ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAbzgZWAOwOYBsCmBpHATwHkAjAKxwGN4BfOAMyghDgHIZCwcBaBnAM4w2AbgCwAKElUIaIXGIAFAKIAlAIIAVYquRwAvHADabACQ4AjmwA07U2hw276J2bQQYASTRsAunABDATgZORhxKQlObgVuKACYaAM4AAponAgGBRUNbV0ASiM0AFcQUhwoXwjJdLhVYtxk1WpoABMAHmI4hOhbISh0DDgAHzh+waNfAD5qqK4cFEHcAkJ6xsNUTGWiMkoadrWcGckTiVD5KAacAC5FrfwiQ+SESTg3uHMLW7YBFhwYAAWgzYkloQA

### Bug description ## Add an exports field to package.json to support Deno I’m an avid user of Deno, which generally provides excellent compatibility with most NPM packages through its Node.js compatibility layer. Unfortunately, I discovered today that type-fest (v4.41.0) currently isn’t supported out-of-the-box due to a missing exports field in its package.json. Since this is Deno-specific, I can’t provide a traditional Playground example. However, here’s a screenshot of the error I’m encountering, which blocks me from using the package entirely:  I tested adding an explicit exports field manually to package.json, and it immediately resolved the issue, allowing me to use the package seamlessly in Deno. Considering the substantial popularity of both Deno (~100k stars) and type-fest (~15k stars), I suspect this issue impacts many potential users, especially newcomers who might abandon usage upon encountering such an error. I’d gladly open a PR to implement this minor change if it aligns with your vision for the project. Looking forward to your feedback! Thanks for your time, Nick cc @sindresorhus ### Repro N/A

### Bug description ```typescript import type { ConditionalPick } from 'type-fest'; interface TestInterface { a: string; } // TS validates that everything is ok - WHY ? // ConditionalPick<TestInterface, number> === {} ..... const test123123123: ConditionalPick<TestInterface, number> = { sdfsdfsdf: 'asdasd', }; ```

### Bug description SSIA ### Repro https://codesandbox.io/p/sandbox/y44dqk?file=%2Fsrc%2Findex.ts%3A2%2C1

### Bug description ```ts import { type Split, } from 'type-fest' type Parts1 = Split<`${string}aa`, ''> // => [string, "a", "a"] type Parts2 = Split<`a${string}a`, ''> // => ["a", string, "a"] type Parts3 = Split<`aa${string}`, ''> // => ["a", "a"] type Parts11 = Split<`${string}.a.a`, '.'> // => [string, "a", "a"] type Parts21 = Split<`a.${string}.a`, '.'> // => ["a", string, "a"] type Parts31 = Split<`a.a.${string}`, '.'> // => ["a", "a", string] ``` ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAbwFBzjAnmApnAymAG2BgBokBfOAMyghDgHINsBaKrAZxgaSWZwAKAQ1gcAjHAC8eQsQA8AAwAkCLlGAA7AObkhQhSUYMAfHAD0ZqaYDaazVsMAiIY6cuAun0yCRMDgCYpGSIYRSEVO21dAyNTCys4a2dXOEiHOGTPfjhhUQBmIPwQsPDVGHUomIYTc0tJG2S3R09ebNy-MQlpIvllMoqdADohYarBmvj6xLSmpqzvHN8AruDekYjy+3JRwwZxuLqGl0MZjI8vbEX8lZ7QhRH1-q2xicPExrOUtM8gA

### Bug description Docs merged into main mention an `ExtractStrict` but I don't see that published in the latest version on NPM (https://www.npmjs.com/package/type-fest/v/4.41.0?activeTab=code). Is this intentional and pending v5 or can a new v4 version be published? ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBDAnmApnA3gUQB4ygQwGMYBlPYYgXzgDMoIQ4ByJVAWhpQGcYmBuALAAoYQHpRcAGr4ANsAAmcHPnAzuw4azTLVKAIxwAvEtwFiZKBRgAedD3wwArlwBczLo8KFuXfnHkO+G48lgB2AOYA2gC61AA+GPZOrswoUPRQfmkZweQRlAA0iTAOzm5MHl4+TJQAfIJC4oa1xaUpFZ7eXL58-oG5YVGxGkJaJipgagBMRiZ4RKTkxNZM2L5wCRVMG8wg25sy+8zYh0Wr65u+9WKizccX7kwjYzqTKADMszjz5ks26Ng3KFHCAAEZpXqIIEg8FQeJwSLAsFpIpI2HRIqOUIAa1CEAA7qEYtdGrcWoiYSi4Gi0tEgA

### Bug description Summary : `RequiredDeep` should only remove `| undefined` if the key is optional and without exactOptionalPropertyTypes. **First bug** : `RequiredDeep` removes `undefined` values but shouldn't ([playground link](https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=true#code/JYWwDg9gTgLgBDAnmApnA3nASigjgV2ChQBMARFFMOAXzgDMoIQ4ByJVAWnpQGcZWAbgCwAKDEc0AMQgQ4AXgwNZALjgA7fCABGKKHAA+cfOpIp6wdaUG0R40ZLgyIOAkVILseQsRIAeZwA+OwB6EM9MelUNLV19IxMzCysSGxoxCWRpWQoqABtEVx8PRSL3ckowANlgsTCI5Qg1TR09NLEgA)) : ```ts type Foo = { foo: number | undefined; }; type FooRequired = Required<Foo>; // = { foo: number | undefined; } type FooDeeplyRequired = RequiredDeep<Foo>; // = { foo: number; } ``` **Second bug** : `RequiredDeep` does not act like `Required` with `exactOptionalPropertyTypes` [(playground link)](https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=true#code/JYWwDg9gTgLgBDAnmApnA3nASigjgV2ChQBMARFFMOAXzgDMoIQ4ByJVAWnpQGcZWAbgCwAKDEc0AMQgQ4AXgwNZAfgBccAHb4QAIxRQ4AHzj5NJFPWCbSg2iPGjJcGRBwEipBdjyFiJAB5XAD4HAHowuAB3YBgACzgUAA8AQwBjGAB5MBhgCE0UgBsABSZUWEQAFWQ+ODUxCLgmxUx6WQ1tPQNjU3NLa1taBsiY+Ih8eGT0rJy8gpKygyRq1F464abvVvatHX0oOxoxCRqXWQoqQsR3Py9FG89ySjAg2VCNluUIDr2DQ7EgA) : Explanation : [exactOptionalPropertyTypes](https://www.typescriptlang.org/tsconfig#exactOptionalPropertyTypes) compiler flag tell TypeScript to disallow assigning undefined to optional properties. This also has the effect of treating `T | undefined` in an optional property as literally `T | undefined`. Previously, it would've just been `T`. ```ts type Foo = { foo?: number | undefined; }; type FooRequired = Required<Foo>; // with exactOptionalPropertyTypes : // = { foo: number | undefined; } // without exactOptionalPropertyTypes : // = { foo: number; } type FooDeeplyRequired = RequiredDeep<Foo>; // = { foo: number; } ``` ### Repro https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=true#code/JYWwDg9gTgLgBDAnmApnA3nASigjgV2ChQBMARFFMOAXzgDMoIQ4ByJVAWnpQGcZWAbgCwAKDEc0AMQgQ4AXgxiAkPVkAuOADt8IAEYooI0cr0BDKAH5NO-YbgAfOPi0kU9YFtLHVwAF5+NroGUI7Oru6e3ip6+AHW2sGGxjTGYgD06XAA6gCSACoAEgDyAKr5cCgAHmYAxjDFYDDAEFpmADYACkyosIj5yHxw6hlZcAiDcDIQOAREpApKopnjq2oQQXZGo6vj5lCbIcYrux4Bh-ZOLm4eXiTHY6ux54lbD6s0O3lFlTX1jc1Wh1uhBekgBqheMMduNJFNZLNCMQSIt0DC1hpXkd0XsLBdQlcIrdostHuMzoEsZdwjcovccXBnpTbNjSR8JJNpoj5ijFNzkQAeaYAPjSbO+hTg0ByBRK5V+dQaTRabS6PUM4MGUJGbNhnNkFCo7UQ-IWijRuoxGyp20tuIONsEcBWvAAFhB8O0UQY4AADFnU66RO6+uDAegK-7KoFq0Ea-pahkU-FOl3uz3etD+pIEmnB0i+hlMlPoz6iOHTQ1gY2m3nYPBI0hVoWyUViIA

### Bug description The `If` type (https://github.com/sindresorhus/type-fest/blob/main/source/if.d.ts) is documented and it's even shows as part of the public interface in the examples but it isn't exported from `index.d.ts`. This might be by design by I'd find it very useful right now and the documentation and examples would suggest otherwise. ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBDAnmApnA3gSQGYF87ZQQhwDkSqAtNigM4ykDcAsAFBA

### Bug description I'm recreating this already reported issue with a better title and label. TL:DR; some missing exports are breaking several types. Original report: https://github.com/sindresorhus/type-fest/issues/1215 ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBDAnmApnA3nAIsA5sGAYQAsBDKUgYxhSjgF84AzKCEOAciVQFomUAzjA4BuALAAoSSgAekWHEoQAdkLgATPAQBc2LUTIVqtOAF5OATg5A

### Bug description Hi there! Upgrading type-fest (only this lib, narrowed it down) from 4.40.1 in a project to 4.41.0 broke our eslint execution: ```ts Oops! Something went wrong! :( ESLint: 8.57.1 RangeError: Maximum call stack size exceeded Occurred while linting /Users/me/proj/src/file.ts:67 Rule: "sonarjs/arguments-order" at outofbandVarianceMarkerHandler (/Users/me/proj/node_modules/typescript/lib/typescript.js:69323:42) at outofbandVarianceMarkerHandler (/Users/me/proj/node_modules/typescript/lib/typescript.js:69325:18) at outofbandVarianceMarkerHandler (/Users/me/proj/node_modules/typescript/lib/typescript.js:69325:18) at outofbandVarianceMarkerHandler (/Users/me/proj/node_modules/typescript/lib/typescript.js:69325:18) at outofbandVarianceMarkerHandler (/Users/me/proj/node_modules/typescript/lib/typescript.js:69325:18) at outofbandVarianceMarkerHandler (/Users/me/proj/node_modules/typescript/lib/typescript.js:69325:18) at outofbandVarianceMarkerHandler (/Users/me/proj/node_modules/typescript/lib/typescript.js:69325:18) at outofbandVarianceMarkerHandler (/Users/me/proj/node_modules/typescript/lib/typescript.js:69325:18) at outofbandVarianceMarkerHandler (/Users/me/proj/node_modules/typescript/lib/typescript.js:69325:18) at outofbandVarianceMarkerHandler (/Users/me/proj/node_modules/typescript/lib/typescript.js:69325:18) ``` I am not sure if whether this is a bug with type-fest or I am running into some weird interaction between libs; the issue https://github.com/sindresorhus/type-fest/issues/805 mentioned the same RangeError but with different type-fest versions. What I'd like to know is whether these errors are to be expected in sufficiently complex projects, and if yes, how they can be circumvented. If it is of interest I'd be happy to try to reproduce the issue in a separate project and dive deeper. ### Repro tbd

### Bug description This might be a problem with [rolldown-plugin-dts](https://github.com/sxzz/rolldown-plugin-dts) and not type-fest, but everything works with type-fest `4.41.0` which is why I'm opening this issue here. When bundling my project with tsdown (which uses rolldown + rolldown-plugin-dts), I get the following error: ``` [plugin rolldown-plugin-dts:generate] RollupError: src/knip.ts(16,14): error TS2742: The inferred type of 'knipConfig' cannot be named without a reference to '../node_modules/type-fest/source/internal/type.js'. This is likely not portable. A type annotation is necessary. src/knip.ts(16,14): error TS2742: The inferred type of 'knipConfig' cannot be named without a reference to '../node_modules/type-fest/source/merge-deep.js'. This is likely not portable. A type annotation is necessary. ``` This can be reproduced by cloning [this project](https://github.com/adamhl8/configs), updating type-fest to `5.0.0`, and running `bun tsdown`.

### Bug description The resolved values appear out of order order in the resoled type: Actual ``` 1 | 6 | 2 | 3 | 4 | 5 ``` Expected ``` 1 | 2 | 3 | 4 | 5 | 6 ``` ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBDAnmApnA3gSQHYwMIA2EAzigCYBKAhtgOYoC+cAZlBCHAORKoC0zKYjE4BuALAAoSTzQAxCBDgBeDJICQAV2zAAxtGwAuOEKjA64iWqhUzAIwgB3I-YgEUNCwwvTkaAHIQ1HaOynA4+ESklDT0ADwAjAA0cABsAHwWcFlwAPQ5cAB6APySQA

### Bug description The 5.0.1 release added some (re-)exports to the main `index.d.ts` file, but the types aren't exported from the original source files. For example, `RemovePrefixOptions` is exported from `index.d.ts`, but is not exported from `./source/remove-prefix.d.ts`: https://github.com/sindresorhus/type-fest/blob/a3189060975934400498e26caa85c60f1472f77c/index.d.ts#L189 https://github.com/sindresorhus/type-fest/blob/a3189060975934400498e26caa85c60f1472f77c/source/remove-prefix.d.ts#L9 This doesn't seem to be a problem except when I configure my library to bundle the `type-fest` types that are used. I'm using Rolldown, with the option `dts: { resolve: ['type-fest'] }` ([dts plugin docs here](https://github.com/sxzz/rolldown-plugin-dts)). I'm not sure exactly what `tsc` flags that sets. For the reproduction linked below, install deps and then run the "build" script or `npx tsdown`. ### Repro https://github.com/jakeboone02/test-tf-exports

### Bug description ``` import type {FixedLengthArray} from "type-fest"; declare const arr: FixedLengthArray<string, 2>; const [a, b] = arr; // ^? string|undefined ``` Using `noUncheckedIndexedAccess: true`. ### Repro https://www.typescriptlang.org/play/?noUncheckedIndexedAccess=true&exactOptionalPropertyTypes=true#code/JYWwDg9gTgLgBDAnmApnA3gMWADxQEwBkUA7AcxgAsBBKKAQ0QF84AzKCEOAIiVQFpWKAM4xuAbgBQk-CgDGAG3pQ0ciCVFxlUAFxxseIqQo06jADyiowcgBo4AJgB8UyWo3wA2vXsAjALpwALxadFIA9OFw0THRAHoA-JJAA

### Bug description Not clear to me whether this is a bug with type-fest or typescript itself. I have a `database.types.ts` file generated by https://github.com/supabase/cli from the types in my database. I am using `SetNonNullableDeep` from `type-fest 5.1.0` to correct some of the generated types. With the attached playground, `tsc 5.9.3` will run out of memory. Reducing the number of properties patched or removing the final `supabase.from('occurrences')` line can cause `tsc` to take "only" 5-10 seconds. The playground itself appears not to run out of memory and to eventually complete. Workarounds are welcome. ### Repro [playground](https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAbzgYygUwIYzQYQDbBoB28AvnAGZQQhwDkAAgM4CuYGARhk2gPSvsuPALQArJnQDcAWABQoSLDgwAnmDSI4AZTQwAchCJ6WePJzxoAImjRg45KjXqr1wimiYwpcuS40ApJkM4AF45ODgAHzhPKGAiAHNwqLgiFhAONChk6I4ICAsMIhzUkzwSpABtAGs0FQAuGJg4xIBdRsDg6JYiABM0Cni0XvsSzqJK1p9ZPzhLLE5uDRDEZLAWDgJkRoRkiIAVcw8dvYi4CA4eKAA3LGBDAH0wAAsIGAgmE9kzn7gAJQgAHcvr9fs90BRGrF4klvqCzsBeo00hksqdQVtiDwHsgIP0oc0YejfhcrrcYPciA9EQSWrD4WceABHZHpTLZOGg0jEiIASSIVxgIIZcHBA1pRM58MRAH5kWhrmipRjgMgsWgcXi0BLEjyzqSsuTKdSkU06XqIszWaiOQzucqzgBVMC9LDa1YOn5iihys2SkVwWXyxW2kWYgUa3H9X3Q3We-WXQ13R5Bv1xgPM30o9l6+0Mv5oMwUwxMZ7AMCfOCVC0egMRCjQNDABJEADSdT0GBA7oARExm88KYknq93kwHv2EoOYSaHhRaioezWIri8OkBY1Kj2DTdk1TET2pvGfsAmAB5IhofYQC-uigYPA8ZdwCFZYhq3oFouUxrbxO74sBSXY8zlfdAiA-HACnXSstwPI8A1IAAaPUEN+PMSX-I0S2FUEAWBWsRQwZBkBYKBiIaUobRSNJTBrPJeko2MEhosoa1xHohSo9lWLokDUEwbBegeLAdXpEVemAdBkEAxp5hgRYeC3dZNlVQ8twAURRJh1J7ZoMEVPAHkk6TAMPXjyhAmk03Ehkd0VYTRJsmt7KyB48AgZA90aHpqiIIEiAsmtWA4UQ0Bk9zPO8uBfP8wFihAhSAA8U1NbMlQDNhXSEkSuOYmsyLwMSgpAlgrhNMTcz1flBVw+FiNI8jkBULM2SyEqAwYlriuiWjLIDDiSFa6jerY-j0DdRy8sJdMJKk8LAN9eTFLQZSNi2XStPSHTWi3fTDOM+aZMpczRr4gNrPykDXKmyrrqwtyPK8xafKIPyAo6kUQrCiKnui2KAprZLUutHNSpdSbcruzKoDwGMZpYs7+pFMq3MuhGqvjZ1svdXYQIasiKOGnikfovFupsz6GUGmBifa0nxsE4Zcvh80QJMhbKSWhYhFWnsVI23aey2kAdr28iDo547DFO0pzpFVMroDG6WehkVXKgSLnq5173viqn4W+hatb3X0AfioGMBS-dejp0MGSyyGsFZ-0Udhl3EgN0FUc1xWMfjDC8MLPdS3LWC0J+QOzjAahBgsSs8fzIE6tBNAQAwYAiuckD7xATOVAeIgu3dZivd+BJgEVKki+7Hq5eRhlgCcpWFbStr7fhGuS4RsufiIVU-OLtWGTAVUYDI7u6V7xkNmH9DqojWAU9+NOM6zluGVz-PC+Lj3EfrmsK6rnfuz36eIib6a2Yu23gwykUu7PhmA375BB9r7OA1HmSJ6fg+QJCnPSOepsZumXj8Vemc941i3ngAuj8659UPpXYgJ80B-yQVZZ2QDfipkvCGGsCDKbPwfgPIhG94Tf3HugDBY0MwbGgQHPUX4Q5lgrJuCOZwo5RwAGqEEBAnYknlGrgTVII+M+FwFnAJk1Si6UoDnzgFgQkHAWCyWIf-Tq5NEF0JFDTUG9NNFzVMj+OYPMlhrVUsgTa2ldL7ULIdExMtWiKPRlPEhjd+gkGAIMLIlZmKTFceOAKDx7LRTyAUTAgUPHwj+uo5avNLGCy3FBcAHxgDYH2GoDwukPJUiLLLTBysHq3Q0UU9WJS5zUBAHJcxSl+brTUkLVJkB+yZOyWLHseT3JYEKbokeo4Pj1GfNEBJFiGlWN0i09J7T1CdOEWRURGoXhvAgOpThDIYmgmBkQWpClEkTOST2aZbSrwdLsVbZxijCo6PllyZhwdAKh3YVWDZowpRRwAGI9GlhuQiECkr6QioiYgFJfFQHEQyAAglABICc4BdWKlHH4BZqF-ICW85FcA0CAqajAB49ijJS3UYneEMK4U7ARdoymWKIiorIn8sZ9SBZNM0rYoWhLHGc2ccSLFf0iVgP+b8cl8KFlQCWbrOKgVaX-F0Ay-x-t7kOjYIKUJWFoqktBCKqREQZEUQMR3UEiLP56IgJxA1NZiWmKZXzFl1ihYi06Zyq1PKQJxOtXU21jT7UpJoK0jJZy5m5MeAUt5PwVbN0VRUskzNHA1LMfs8Zdqpl+pmYGnJQtumhprCssceyVpJNZcc1NpyslBqFmKpZI5VnrMttbfNBzk3NJLQGstGa9qXKIIeAqYAKomodrDHBEQZX0qgOiqNwCPmnEdcvcMPBhnxmiD2EiAAGYCmy4DLuQMIDgi49RLpIjulQwgILrvhAe7du7hBMAwGe0EF6j0nt6He34D6r0QWvbe-dm7D3vu3X0F9Pwl3+UvIBmIOLfzpwsD2FIPZ3BQbQGB51R1ZLfp7P5WAzwwMRGA9AGAzxMCeGw7BwjMBiNLqCGogj3AyNoco-h8jm76PPEBB4Wji7N2saI2hjD+GuPscnT8E5raOnL0kt2AUlJIXwgIwOLi8jp6AkRPhg1Zc+VYHcokKRRZVNbLOHgLT3FDHlME78LNTlNVmcMLpoxGInIKb01iyt75lmDKkcouIqj1Glz0xEPO3Y-C3Ibr8JgUBthlP6b8fDbIgt6jne6G1hafXC3ZVueLfS7lcOJDsqRTBkCEG8YMZAaDYvxhDEXUiZhNZd1KwyJg6h8seD7Q52zWWp1wntPaXw2SE0rQAOoZNeGo-k2Ax0PiYKEOAZ484wAADw2qQpuh4DwRtZCLngLQbAVo9gAHzTFmNYe8JgYBaGQAR9Ok2bUDfw2amAq2xuPkqBpXFxE5sLggBQXrvNFuHLUjto83X1BwEOJsDws3kiHYwMd0752MAg4sJ2bsZ4oBnjAE87FgLiC9CYKcaI73PsAApIfQ7O6vLc8OM1wAAGRzAGFDvAJ3Sfpy3HwtAAjDwAEpceaDy7Dxo+OvtLGu0Nu7JA1vjfsChOEFPEcaBxdgPoE3icM5h6vGXxdkeo-R-LrHE3LO89XvzuoH3Bc8GF7d+762ccddODKOAAuieevN8NsXD2mCVGV4z2H6ukco7R1JrcBv06HiFhTna1O9RXcGxb13VuPd05J97o4svNf+5LIHpnt7WhC1Z+z1oXOpR3wUSsfBWQpc7cuwnlXmefdoFT9rzHivCJB4wEblQJuo83Zd6Nq3cgMJ28d4ms30fu-i8e571X6da-14D32TPIfydHHD1T4kneReW-G-Ho71ek+g5T37p5GfYcL57LnnaHPKi15cTrpvlm6XJ0DEQdwCi-inCjnb1-hfUgKnvnJKvXu1dk8NcD8pMMcFdsd7djdCcJ9M9F9Qdl9I9-9J8MAWd+Fz9bc4AickDYCeww9zIV94wYDYdUC2dz8t96cACp8gDfctcpNr9G8IC78zhJFH9n9-heViQP9iQi9TgeDZBAcNAw8aosg5sIdsDd8EdgDaCSwwDdducBciCydcCl9u0pRogkAW828O8ncR9Rce8JdkJkha9ZCm9FCqC98pC08BQTDGDThNDID29Ps18Y99DHxkh38HDtCh80Bnc9Cx93czC4dqC68QD0859j9s84D45VCfgi9JtS8oBy9K9t9KCgiLCaCrCJsb9bC4R7CFCdCu8-C3c+9kg7dnDR83dyDE9AD0iQjpCBQj9V4T88Ddor8bC9diRhCl5WD2peQ38MC+iv8Ejkg-8UjkDp9QjrDsiJsFDxClCWiMDAioj21AiJj6imB6DwCOj4wuiuJ4g2DBilVQQ7dDjfg+DYjv8CF+DZAcVFB4BZgw9QFsBwc4RVjgiZ8ZDpj5CoDacxicCFi1CedM8tCnCCj19Y8DCpcDhgj2jfiKDxj3jJisiGDtifg8ifjyiije8bcpQ7d8jvDfCN9x85jzDJCMjD9wimjIjlD4CYizg4iS8f9Ei5AK8Vg3jaiPipiUTm9gTPDQSCTdCiTrd+9TcfDBSITiS-iJC0B991jGjg9qSWjL9gjNjdchUIgnj3R9j2pHR+jcS4BdShimSRi4TqjSSZTLCG8ti+TTSd95iVDOEyiSSUCaTojdp2SyS6jMjVTb8QEIZsBGhtSFFDSjjfg7cQyzjLj74Ig+C5Bbi8NlAetHUXiIhAiRZZTMj2jvjHDbTUi2Vto6ScMgS+cbTMShTJdkh0zi5YS0yUQMyrS1T9deT8T+txTXDrdh0MCWzeZCSJSAjnSqzyTZ8W8T9HVCy4AGSozmTZBWTczkDByvSGzfTcjmyMSwSXD-CSi4Qyj1yKi49az0h6zhz59qSxzdoFy0JRj4TM8FzOTkTrTZipSlCzzFjnT8zRZ1IDyQAjySxOFYybiko7jEygdhNZkwdkgAAFb1UC9NH8rkrY7MjvN84tNJUtc5ThdQmIVcnMssvsisuEGCttWXWEqCqxQi7JOC+8xsuw7Crw1swooU9wrstcgUhivsyoUirYci9QSi+UrPZtVCkTctXgqc+IpkpIlYTi1Ubii0ocz47k0ldEnC3crE8bLciIHc1i8E9sji6CltMC3iykhUgS-1MCsWGS2XS8uAKS5ACyy00A6Y0s5CmSnaV8p85nFC0y9NMWGyuyuSgUP8qc6YeMpQXEAUeAKCcKooGACbFYUlO1OqGddUuAeLTcPULdNdKE+ELdI9HsLK0EHKv9PK9K39Y9G9Yq+MQq49ADfK34Kqk9bdcq2qn4eqj9Gq9KkDRDZquAVobqngJKTcHsBDPKzdeDB8RDXq7LCWBxF1XZKsDqvDLDbqiIdDRa0jCqhkHsda5apjW7ajIjHavsPaja7K5jfjE6gq86w63jFjNjC6s4Saj5LKww2QcgbgFAEsGAfbHrCCrAUnXoG1SbHQfQQwYwUwI4awWwebT1LKugO1AAOjP3hucwgg8HhvwnhsRDoCiGSDhu9URrQORpIkWRcyYHRqBExq8TBUIAhWxsiFxoRqRpRrEXJsBHhvdUMDpoZvxqZuJvFVJtZvZqikAnZqwC5rhDxqsQJtIKJpEQFoxo5qICFqIHFoiElq2GloEVlpJtRrJoxojS8BxolsZsJuZrRoxtzQ+FVvoBNplrNr1opp2WtvVtVE1rJvtsFp2XhrywK2puKy7joBZJkGuLCs8BiC215kmwEjdHwF9tm1+pgH+oWxtu9ToB2wJzoAbAgDoEWzoC4CgDoA52DoEBWnhrjQzvtsLuDqAA)

### Bug description It ends up cutting all strings down to the length of the shortest string ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAbzgZRlYA7A5sgNsAYwFM4BfOAMyghDgHIYBPMIgWgqIGcY6AoXpixT5iAEzgBeFGkw4RRADx0AhgDoAFkVy4IdOAB96agO4RjdADRwATAD5ecR44D0zuAD0A-A6dxerlHUIAFdccQAjEjpNbV0DelNzIA

### Bug description In the example below, the onChange function should accept `true` as the second argument. With the old `IsEqual`, it does; with the new type, it does not. This is an extremely abstracted example, so let me know if you need more context. ```ts type FieldProps<T1> = { onChange: <T2>(value: T2, shouldBeTrue: IsEqual<T1, T2>) => void; }; const TextField = <T>(value: T) => { ({} as FieldProps<T>).onChange(value, true); }; ``` ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBDAnmApnA3gSQM4FECOArgIYA2AvnAGZQQhwDkSqAtFStjAwNwCwAUAOZoA8qQAmOAiVIAeAIIAaOACEAfHAC8AgJAAKWQHE1egJRaNhuCgAeMFADtx2OPLgAyOFYA+XuAH44AEY4AC44ACZzW3snbF0DYzMLPxjHZ1UPP18rQJDwqN0dQJgoQhQi8KoybBQ+QX4Aeka4ADkUAHc4KSIyOBY4cQgOOAcIeA7oAGsBIWQ0ADFgFAkABVowbFkAFSCNTQwBODgIBwBhAAtiBwBzFHCdiJMANzJy8O2I5WwLiEIJFQobZle7dPC9OS7ZSfNTmTQaZ4QYDierkeoCADGp04cG2MSWK3EWjgO0ULzeoO2cI06COcD06EoxBcBLWGy221hADpTpdrnc9K9SOVlKVyqZUeimi0xESBpMoFMXMzrDZUBj7OJZvxhHBZazxOsIJsdntibT+MdeVdbqDHuThZSvnAfn8AUCQeFZT0ZKboU9qXBEcjJdqsQ4cbK8XYDcTSQ73rjAxbjgymS59cs2caOdzrfyUIKKaKQRKBGigA

### Bug description **the correct operation of this utility depends on the order of types!** Let's say there is `interface Pokemon` like this: ```typescript import type {MergeDeep} from 'type-fest'; interface Pokemon { name: string; type: string; } ``` **valid** : ```typescript const testThroughAssert: Pokemon = {} as MergeDeep< Partial<Pokemon>, Pokemon >; ``` => `success` **invalid**: ```typescript const testThroughAssert: Pokemon = {} as MergeDeep< Pokemon, Partial<Pokemon> >; ``` => `error TS2322: Type '{ name?: string | undefined; type?: string | undefined; }' is not assignable to type 'Pokemon'.` ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBDAnmApnA3gWRVA5igERRTAF84AzKCEOAciVQFoKUBnGOgbgFgAofsAB2MHBQCGAYzQAFCAGsUICEIz84GzUPEgUALjgcow3Lz6bNjfYZjGhp9ZtL9+klRwTsYAFQAW1AFdcXwBBNjYcGAM5RWVVAF4McnE2OGw8QmIwAB5HCxilFQAaPM0ZcVhgcQAbbIK4gD5Shq4gA

```ts type Foo = { foo: "bar" } | { bar: "foo" }; type Bar = { foo: "baz" } | { baz: "qux" }; ({ foo: "baz" }) satisfies Merge<Foo, Bar>; ``` results in error: ``` error TS1360: Type '{ foo: "baz"; }' does not satisfy the expected type 'Merge<Foo, Bar>'. Type '{ foo: "baz"; }' is not assignable to type '{ bar: "foo"; foo: "baz"; } | { bar: "foo"; baz: "qux"; } | { bar: "foo"; foo: "baz"; } | { bar: "foo"; baz: "qux"; } | { bar: "foo"; foo: "baz"; } | { bar: "foo"; baz: "qux"; } | { bar: "foo"; foo: "baz"; } | { bar: "foo"; baz: "qux"; }'. Property 'bar' is missing in type '{ foo: "baz"; }' but required in type '{ bar: "foo"; foo: "baz"; }'. 15 ({ foo: "baz" }) satisfies Merge<Foo, Bar>; ``` However, this does work: ```ts type DistributedMerge< A extends object, B extends object, > = A extends object ? (B extends object ? Merge<A, B> : never) : never; type Foo = { foo: "bar" } | { bar: "foo" }; type Bar = { foo: "baz" } | { baz: "qux" }; ({ foo: "baz" }) satisfies DistributiveMerge<Foo, Bar>; ```

### Bug description My primary use case for SimplifyDeep is to get index signatures to play nicely with interfaces, but since https://github.com/sindresorhus/type-fest/pull/1293 this has no longer worked for objects with arrays of objects. This is the because arrays are getting skipped for simplification now. The PR states reasons for maps, sets and etc, but no reason is given for including arrays on there so it feels like a mistake. I'd like to see any easy way of doing this again by either removing "UnknownArray" from the simplify skip or some other method. Thank you. ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBDAnmApnA3gZVGANsAM0QBEUUwAaAYQgDsATYGYOgQ123HyNPIrgAKUUE2AA3FAF84BKBBBwA5ElQBaAigDOMRQG4AsACgjAegBUZowFlWMAMYALLXFa1EcMMJCiJ-AAZiEMD0fv7EtiihcNBwfgBKKADmAKIAHmB+cGLsAK4oAHRGZiZGKOnQ8CpoAEI5wLgwAJK0mnAAvIJePmgAPllB9HB94TC9cAkp6QbGhuaWhjb2Tq20dKpQKHY5UJriaFWahYbFpeWwCMhoAHJ0CVs7ewAql+1wtfVNLUNwAGI5tHZmHRvgAKWgoADucBB+VhrCgiRyIBQtBgmgA+gAuFxuADaAF0AJTtAB8cH+AGtVhDaMS+kJ5MBNCgADyU6m0EnTU6Qc5VOA2MCaADyUEwKDRrwSrHodFwiEFbNoVIgNP47NVnO+AHUUKwKYrdfqANIoRDq5Ucsl9aWy2jy8UwJUqmnWuBGimOlke02ILlGHkVC6oOCcPCEEhkMAAJhZz1Q-DSdlwOXoKHjaA64IkUDJbSMAEgaAxRGwODhuJHyCzCwWMxRC0mU2mM98brQ7ttdhJW31BSKxRLNA3DAWIAAjABWmxghf9MyM-IAUphhVchCJmBJXtphLREt9aEjxygoN9xxAILg9bRDzlcLhpsvV1cAGq5TNwFdrjfeLdjb8rmFKcZ2+QD3xTFACSfF5AOA6dAVedA4FxCkzWxXdgH3fFsXAj84EkblDGTVhNFaTAYGgVklzgMpRgYVo4JAwEyXQSQA0MLDRigAhWDsNAfg+U9GlGBR0CMOAZGAFBcHoDCYD3RJpkk7JIIAfmxVxEGmdiZi409eP434hKgKwIDTXAMAkuAmBQEBNGxQSGmE0SCSMXTTBMOA0lQRCYAcJkEAgOAIWgCk4HHHJ4FWOBcDoRJTzgWVnExEEjDsOhtDgbQqNecEoQoqiWTDSteDAFknO4syLJJEkQUJDiTC87UwtafA0IilACFyiEnFvVZ4E0ClgDAMAsIPeEoFYRBNHSzLBsojZozyyFQ0W1kSojMrY0q09qpk2r6qAA

### Bug description ```typescript type Foo<T> = { bar?: { baz?: T } }; type Test<T> = SetRequiredDeep<Foo<T>, "bar.baz">; ``` ``` Type '"bar.baz"' does not satisfy the constraint '"bar" | ("baz" | (_Paths<T, { bracketNotation: false; maxRecursionDepth: 3; leavesOnly: false; depth: number; }> extends infer SubPath ? SubPath extends string | number ? `baz.${SubPath}` : never : never) extends infer SubPath ? SubPath extends string | number ? `bar.${SubPath}` : never : never)'. ``` I think it's because `Paths<Foo<T>>` is not including `"bar.baz"` for some reason. ### Repro https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBDAnmApnA3gZRTASigRwFdgoUATAERRTAF84AzKCEOAciVQFpGUBnGOwDcAWABQErmgBiECAB4AKgD44AXgxwARgEMoAfgBcWvQC9jcJXAZ0x46VYExlazdjyESZKjTAK5RVUAGjgAIj0oADpzMJV7IA

### Bug description let's say there is a type ```typescript type TestType = | { optionalField?: number; test1: number; test2: string } | { test1: number; test2: string }; ``` so ```typescript type OptionalFieldType = TestType['optionalField']; ``` => `TS2339: Property optionalField does not exist on type TestType` => its correct, BUT: `IsUnion<TestType>` = false ```typescript const test: IsUnion<TestType> = true; ``` => `TS2322: Type true is not assignable to type false` but `TestType` - union....

### Bug description let's say there is a type ```typescript type TestType = | { test1: number; test2: string; test3: number } | { test1: number; test2: string }; ``` => ```typescript const test1: UnionToTuple<TestType> = [ { test1: 1, test2: '2', test3: 3 }, { test1: 1, test2: '2' }, ]; ``` => failed type `UnionToTuple<TestType>` infer to to type `[{ test1: number; test2: string; }]`