☁️ Nx Cloud Report

CI is running/has finished running commands for commita4c9e0c. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

Sent with 💌 fromNxCloud.

👷 Deploy request fortypescript-eslint pending review.

Visit the deploys page to approve it

Thanks for the PR,@RyanCavanaugh!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

🙏Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently onhttps://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitorsper day.

Codecov Report

Merging#5018 (a4c9e0c) intomain (7e7b24c) willincrease coverage by2.46%.
The diff coverage isn/a.

@@            Coverage Diff             @@##             main    #5018      +/-   ##==========================================+ Coverage   91.32%   93.79%   +2.46%==========================================  Files         132      286     +154       Lines        1487     9795    +8308       Branches      224     2930    +2706     ==========================================+ Hits         1358     9187    +7829- Misses         65      328     +263- Partials       64      280     +216

Flags with carried forward coverage won't be shown.Click here to find out more.

The issue withobject as a suggested replacement has always been that it's really hard use (microsoft/TypeScript#21732).

Once you've got anobject, you can't really do anything with it:

functionfoo(arg:object){arg.foo;// can't access random propertiesif('foo'inarg){arg.foo;// can't do guarded random property access either}}

repl

So as a "type meaning "any object"" replacement -object is not great!

OTOHRecord<string, unknown> allows you to operate on the variable as an object and do everything one might expect of an object - so for the general case it's much more usable:

functionfoo(arg:Record<string,unknown>){arg.foo;// can access random propertiesif('foo'inarg){arg.foo;// can do guarded random property access either}}

repl

Really once you've got anobject, you need some form of a user-defined type guard to get away fromobject - and most cases that type guard will convert it to aRecord<string, unknown> anyways.

I don't feel like you addressed the scenario (spread) covered in the OP. All of the workarounds make the resultant typeless safe by adding an index signature tom that allows arbitrary reads/writes, and you said the entire point of the default of{} wasabout not creating big type holes

Is it common that people want to spread anunknown?
I personally haven't seen too many codebases attempt such an operation, but I admittedly am not exposed to a large spread of other codebases now-a-days.

Definitely correct that it's technically a safety hole in of itself.
Ideally the suggestion would beReadonly<Record<string, unknown>> - but people get angry when you suggest long types like that without a fixer - generally leading people to just use VSCode's quick fix disable instead.
Also from experience across TS codebases people tend to not usereadonly too much and instead rely on implicit assumptions that thou shalt not mutate this.

I'd be more than happy if you want to specifically mention the spread case in the error message to help inform people of the right way to do things!
But I don't know if usingobject as the defacto "any object" replacement is necessarily the best thing to do.

The reason I bring this up is we found some new breaks (e.g.https://github.com/facebook/docusaurus/blob/c16a08cba59bea5e48d3a79cee82c23aaae29876/packages/docusaurus-theme-classic/src/theme/CodeBlock/Container/index.tsx#L26 ) due to TS 4.7 treating a spread ofnever as an error (since, in reality, we have no idea what's about to happen). Thebest assertion here is probablyobject (which used to be banned byban-types, which I'm guessing is why the author didn't use that), with the second-best being{ }, which is also banned. So instead they asserted tonever, which is a) super wrong in code that actually executes and b) now broken.

If people want an object, meaning something whose proto is at leastObject.prototype, thenobject really is the best fit for that. The variousRecord things here are distant seconds and thirds IMO. It feels like the rule didn't recommendobject due to its old default configuration also banning the use ofobject, which I was glad to see removed.

Sort of an aside and I'll likely be opening a new issue: There's just a lot of confusion likely to come down the road on this specific ban in general, since we're likely to change the definition ofNonNullable<T> toT & { } in 4.8, and are already in 4.8 going to change the default narrowing rules such that a truthy narrowing of a value of an unconstrained type parameter becomesT & { }. Having typescript-eslint, out of the box, ban you from writing a type that TypeScript itself is inferring under totally normal operation, is awkward.

The rest ofban-types is totally solid and I'd really raise reconsidering{ } being in the default ruleset forban-types, since the other bans it defaults to (String,Object, etc) are extremely well-grounded.

FWIW,props as object doesn't fix the spreading props problem either.

I'm ambivalent on banning{}. It's useful for people who understand what it does, but it doesn't follow new users' intuitions (although there's nothing unsound about it; you can write{ length: number } and assign a string to it as well).