no-undef-init vs init-declarations using try/catch

How would you propose assigning data in a try/catch?

For instance:

let data;

try {
  data = somethingThatCouldGoWrong();
} catch (error) {
  // handle error
}

We currently disable @typescript-eslint/init-declarations to overcome this problem.

Another workaround would be:

let data = undefined;

try {
  data = somethingThatCouldGoWrong();
} catch (error) {
  // handle error
}

But this would mean I need to disable no-undef.

In Vue, for example, the template needs the variable to always be defined before it can reliably be accessed.

This is an issue I bumped into while working on #577, but it seems too broad to mention there.

[EvgenyOrekhov]

@alexkramer98 I see. Let’s disable init-declarations and @typescript-eslint/init-declarations for .vue files in https://github.com/EvgenyOrekhov/eslint-config-hardcore/pull/577.

[alexkramer98]

@EvgenyOrekhov I would prefer init-declarations to be disabled. (Maybe just for .vue files?).

Unfortunately, your approach of keeping the variable in the scope of the try-block is not possible when that variable needs to be accessible in the template at some point when using the composition API (which Vue 3 has quite strongly moved towards).

<template>
<span>My data is: {{ data }}</span>
</template>

<script setup>
try {
  const data = somethingThatCouldGoWrong();
  // do something with `data`
} catch (error) {
  // handle error
}
</script>

<style>
</style>

data would not exist in the template.