Thanks for the PR, @asmundg!

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 on https://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day.

Codecov Report

Merging #1779 into master will decrease coverage by 0.20%.
The diff coverage is 79.88%.

@@            Coverage Diff             @@
##           master    #1779      +/-   ##
==========================================
- Coverage   95.20%   95.00%   -0.21%     
==========================================
  Files         148      159      +11     
  Lines        6989     7080      +91     
  Branches     2017     2021       +4     
==========================================
+ Hits         6654     6726      +72     
- Misses        124      154      +30     
+ Partials      211      200      -11     

I'm curious what the motivation behind this rule is.
With noImplicitAny turned on, attempting to do an index access on a variable typed as {} results in a TS error:

  const x = ['a'].reduce((acc, cur) => acc[cur], {});
//                                     ^^^^^^^^
// Element implicitly has an 'any' type because expression of type 'string' can't be used to index type '{}'.
//  No index signature with a parameter of type 'string' was found on type '{}'.(7053)

Additionally, {} has no properties, so you can't do . member access on it.

It seems fairly safe without a lint rule.
There is also #1707, which is similar to this rule.

See https://www.typescriptlang.org/play/index.html#code/MYewdgzgLgBAZiEAuGBvGBtA1gUwJ4wCWYM0ATsQOYC6A-CuVTAL4wC8mARLnp9QHRkcAEwCuwHAApJAQ2DAANDGCiyASnYA+GJPT99cxZhVlqKAIws1S1MzUAoewHonMAEqiSUQgFscMABU8AAccAFEyMhAyewQQfh5afmgZMigIAHVCKAALSU5ONSA for a minimal example of how untyped reduce with a {} initial value can blow up at runtime.

You're right that you can't read indexes of the {} type, but you can assign to its indexes and you can assign it to another indexed type, bypassing the type checking in a way that none of the strict compiler options will catch.

#1707 is related, but it deals with where the type argument is provided. Which seems like more of an aesthetic issue than requiring there to be a type argument like we do here.

I don't think creating a rule that just handles the case of an array reduce is a good solution to this, as this can happen in more places than just a reduce.

let x: {} = {};
x = { ...x, a: 1 };
const y: Record<string, string> = x;

The specific problem here is that {} can receive any object-like type, and be similarly assigned to any object-like type.
So a better solution would be to have a rule that bans the assignment of an {} typed value anywhere, to help catch this unsafety.

I agree in principle. This is reduce-oriented since

1. That's where I've seen people make this mistake
2. I'm not sure how a rule banning assignment of the {} type would be implemented

If you have some pointers on 2. that's definitely something worth looking into. :)

Sorry, this got lost in my notifications.

This could actually live in the no-unsafe-* rules.
We could treat {} as an additional unsafe type (same as those rules treat any).
That would save you having to implement it from ground up!