Proposal: Add option to allow sync methods at root level in no-sync

Current state

In Node.js, requiring or importing a file/module is synchronous. Therefore, making more synchronous calls does not hurt anyone, it just slows the loading process down a bit. I believe the rule’s intention is to warn people if they accidentally or intentionally make a blocking call in a place where it could seriously hurt performance (ie. in a hot code path etc.).

Currently, the no-sync rule is either enabled or disabled, ie. either you can use sync methods or you cannot.

Intended state

A new option is introduced to the no-sync rule: allowAtRootLevel (bool, default false) (exact name is subject to discussion, I don’t really think this is appropriate). With this option turned on, ESLint would not warn on sync calls appearing at the root level of the file.

Examples

// no-sync: [1, { allowAtRootLevel: true }]
// index.js
// ok - appears at root of the module
const contents = fs.readFileSync('/super/important.txt')

module.exports = function getImportant() {
  return contents
}

// no-sync: [1, { allowAtRootLevel: true }]
// index.js
module.exports = function getImportant() {
  // not ok - not at root level! (no change to current behaviour)
  return fs.readFileSync('/super/important.txt')
}

The goal is to avoid turning this rule off on a per-line basis at the root of the module when ie. contents of a file are required for the module to operate.

[VictorHom]

If no has started any work, can I jump in to help out with a pr?

[platinumazure]

@robertrossmann Thanks for following up! We need the rest of the team to take a look. Unfortunately it looks like this just completely slipped through the cracks, and for that I apologize.

This enhancement seems reasonable to me (helps that it proposes an option rather than change in default behavior), so I’ll champion this.

@eslint/eslint-team Could we give this a review? Just need three 👍s or, if this doesn’t seem like a good enhancement, let’s talk it out.