DEV Community

The Strictest TypeScript Config

Vladyslav Zubko on December 13, 2023

Most people know that to make projects using TypeScript "strict" in terms of typing, you need to enable the "strict": true option in the tsconfig. ...

Read full post

Yeom suyun • Dec 13 '23

It's quite fascinating. However, noUncheckedIndexedAccess can be a bit restrictive, which is a bit disappointing.

For instance, it raises errors in cases like the following:

for (let key of obj) {
  obj[key].func(); // possibly 'undefined'
}
if (obj[key]) {
  obj[key].func(); // possibly 'undefined'
}

Vladyslav Zubko • Dec 13 '23 • Edited

Hey @artxe2 !

I think the issue lies more in the for...of/for...in loop, as it returns a string for a key variable. If you typecast it, everything will be fine 🙂

for (let key of Object.keys(obj)) {
  const typeKey = key as keyof typeof obj;

  obj[typeKey].func(); // ✅


  if (obj[typeKey]) {
    obj[typeKey].func(); // ✅
  }
}

for (let key in obj) {
  const typeKey = key as keyof typeof obj;

  obj[typeKey].func(); // ✅


  if (obj[typeKey]) {
    obj[typeKey].func(); // ✅
  }
}

Yeom suyun • Dec 13 '23

The solution you provided might not resolve the issue.
TS Playground

var obj: Record<string, { func: Function }> = {}

for (let key of Object.keys(obj)) {
  const value = obj[key]
  if (value) {
    value.func();
  }
}

for (let key in obj) {
  const value = obj[key] as { func: Function }
  value.func();
}

Vladyslav Zubko • Dec 13 '23

Oh, I see.

I understand what issue you're talking about. But here again, the problem is not with noUncheckedIndexedAccess, but with index signatures. If you explicitly annotate all keys, there won't be such an error. Here is the same playground but this explicit keys.

In my article, I repeatedly mentioned that the index signature is a bad thing 😁

Yeom suyun • Dec 13 '23

Yes, indeed.
If you have been using the strict option in TypeScript, applying additional stricter options may not introduce many new errors.
However, for types like Array or Record, there are clear use cases, and it's not accurate to categorize them as inherently bad.
For instance, I found type casting cumbersome in cases like the code below to eliminate errors.

/**
 * @param {string} text
 * @returns {string}
 */
let _default = text => {
  let regex = ""
  let len = text.length - 1
  for (let i = 0; i < len; i++) {
    let t = /** @type {string} */(text[i])/**/
    regex += first_consonant_letters[t] ?? get_letter_range(t)
  }
  return regex + get_letter_range(
    /** @type {string} */(text[len])/**/
  )
}

Vladyslav Zubko • Dec 13 '23

Agreed!
In general, as always, it depends on the situation 😁

Volodymyr Yepishev • Dec 14 '23

Just dropping my 2 cents, the possible undefined problem of the aforementioned record can be solved by an explicit cast in the value lookup, it's just that both the object and its key need to be casted.

let obj: Record<string, { func: Function }> = {}

for (let key of Object.keys(obj)) {
  (obj[key] as typeof obj[typeof key]).func(); // ✅
}

Though the case seems rather artificial, as you'd probably be using .values or .entries :P

Vladyslav Zubko • Dec 14 '23 • Edited

Hey @bwca !
Thank you for sharing your approach to solving the problem!
I believe it's challenging to assess it solely based on this small code snippet. In real projects, everything can be significantly different 🥲