#848 (comment)

... 99.9% of the time, you don't want to use it, and the vast majority of codebases won't want to use it. IMO that makes it a great candidate for banning by default.
In the 0.1% of the cases, you can use a disable comment and clearly justify why you're using the type, or you can override the default config (should have a better config solution for the 3.0 release).

We build the recommended set and default rule configs for the majority of users, not just power users.

Most users will not want to use it. For the most part it's a bad type to use because it's nigh impossible to use due to microsoft/TypeScript#21732.

I do recognise that there are perfectly valid use cases for object, and depending on what your project is, those uses may range from "never ever used" to "use frequently".

For example;

• A project like a utility library that provides a general-purpose API to consumers, will likely have frequent uses for the object type to allow consumers to pass any object in. That's perfectly valid and likely to be frequent throughout the code.
• A project that's purely an application will likely have strict types all the way through the codebase, so introducing an object into that stack will likely be problematic and potentially unsafe. So in those cases using object becomes the 0.1% case.

The vast majority of our users fall into the latter category - they are working at some company building out a product such as a website.

If you fall into the first category, then you can reconfigure the rule as appropriate.
We don't currently have a means to just turn off one part of the default config - happy to accept a PR which adds in the ability to do something like { types: { object: false }, extendDefaults: true } to disable the default option for a specific type.

OK -- that lines up with my understanding, at least; if our usecase of needing it as a base for a generic is really that specific in the grand scheme of things, I'm happy to run with that, I just wanted to make sure I wasn't fundamentally misunderstanding the situation. If users really are running into trying to use it as an actual object type when writing business logic, then yeah, Record is obviously a superior alternative. You've obviously got more of the data regarding what the acutal in the field use is, so if that's the case that makes perfect sense and maybe we'll even benefit by having to limit use of object in the wild as is. It's a shame that the in situation isn't resolved since being able to type refine an object using that would really be the best of all worlds, but c'est la vie :(

Definitely - if in worked, I'd recommend object instead of Record<string, uknown> everywhere, as it gives you the absolute safest experience then.

But without that, object is pretty useless. This also sucks because unknown refines to object via a type foo === 'object', so it makes unknown a pain in the ass to use as well.

But I still recommend unknown as it's the only safe alternative to any.

Oh yeah, any is the first brick on a slippery slope to a hell codebase, I've watched it happen. I guess I just figured our use cases for object -- for some data modelling stuff and also as a base extends for generics where basically we want to say "anything that's an object" -- were more ubiquitous in use than they actually are. Thanks a bunch for the conversation and checking my logic on this!

@daviduzumeri for what it's worth, I'm with you. ban-types is one of the first rules I disable entirely, because I resolutely fall into the 0.1% camp with you, building APIs where it's utterly impossible to know (or enforce) type structure in the inputs my APIs receive. I appreciate the default rules must be created for the 99.9%, although I'd put good money on the split not being quite that dramatic in practise.

#2137 was released with the latest version which will allow you to specifically turn off the ban on just {}.