Repository: TypeScript
Issue: Make `satisfies` configurable to allow excess properties in nested values
Labels: Suggestion,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

satisfies + (known properties, unknown properties, excess)

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

<!-- A summary of what you'd like to see added or changed -->
When using `satisfies`, the value should be allowed to have extra properties.

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->
`Satisfy` is defined this way when I Google it:
>meet the expectations, needs, or desires of (someone).

Right now, the `satisfies` operator does more than that. It's more like `satisfies and goes no further than`. Example:

```ts
interface User {
  name: string
}

const john = {
  name: 'John',
  email: 'john@gmail.com',
} satisfies User
```

In the above, the value of `john` clearly does satisfy the interface `User`, but the compiler complains:

```
Type '{ name: string; email: string; }' does not satisfy the expected type 'User'.
  Object literal may only specify known properties, and 'email' does not exist in type 'User'.
```

The first line of this is straight-up untrue! And it'd be really useful to be able to say "I have an object which I know is assignable to `User`, but it also has some specific extra stuff which I still care about.

## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->
This first arose writing a very large, nested, complex config for a CMS. Right now it's a huge `as const` expression, which we have to carefully align with a type `Config` - but the type only defines _some_ of the properties a config can have at compile time. The value is later passed to a function which expects a valid `Config` so we see invalid configuration errors in the wrong place. We have tried to use `satisfies` but hit the excess properties error for those properties not defined on the `Config` type. It's nested so we can't do `satisfies Config & Record<string, unknown>` except for top-level properties.