Declaring a function inside a try/catch prohibited by "no-inner-declaration"

[davidystephenson]

I find myself wanting to create a function inside a try/catch block. For example:

async function uploadImages () {
  const profileUrl = buildProfileUrl()

  const picturesUrl = buildPicturesUrl()

  try {
    const profile = await getProfile(profileUrl)

    const pictures = await getPictures(picturesUrl)

    async function upload (picture) {
      return uploadImage({ profile, picture })
    }

    const promises = pictures.map(upload)
    
    return Promise.all(promises)
  } catch (error) {
    throw error
  }
}

I want to declare upload inside the try so I can take advantage of profile being in scope. However, this apparently violates the no-inner-declarations rule.

Can someone explain why this rule is important here? Should no-inner-declaration perhaps not apply to try/catch?

[feross]

You can fix this by making your upload function into an expression instead.

const upload = async function (picture) {
  return uploadImage({ profile, picture })
}

However, this raises a good point. Now that ES6 has shipped everywhere, block-scoped functions are supported widely. Perhaps we can disable this rule now? Anyone have thoughts?

[mightyiam]

It seems that indeed functions should be allowed. From the rule docs:

The function declaration portion rule will be rendered obsolete when block-scoped functions land in ES6, but until then, it should be left on to enforce valid constructions.

Regarding variables, perhaps we should allow them as well and so disable this rule and enable block-scoped-var, instead?

Disable checking variable declarations when using block-scoped-var or if declaring variables in nested blocks is acceptable despite hoisting.

[feross]

Regarding variables, perhaps we should allow them as well

Variables are allowed. This rule is set to only prevents function declarations.

re: block-scoped-var

I'd like to move to const/let only so that eliminates the need for such a rule. #633

[mightyiam]

Thank you for the clarifications, @feross.

Then, it seems to be clear that we just drop this rule and enable no-var, right?

[feross]

Yep.

[feross]

This will ship in standard v15.