New rule: no-implicit-module

Please describe what the rule should do:

Disallow module scope variable declaration (variable that are not declared in function or Object).

What category of rule is this? (place an “X” next to just one item)

[ ] Enforces code style [X] Warns about a potential error [ ] Suggests an alternate way of doing something [ ] Other (please specify:)

Provide 2-3 code examples that this rule will warn about:

This should warn:

abc.js

var a = 0;

function test () {
  return a + 1;
}

While this should be OK:

efg.js

function test(a) {
  return a + 1;
}

Why should this rule be included in ESLint (instead of a plugin)?

Like no-implicit-globals disallow global variable and function declaration, it could be a good practice to disallow global variable inside a module scope (global variable are often a bad practice, not only in JS)

[not-an-aardvark]

I see – so if I’m understanding correctly, the goal would be to avoid global mutable state in modules.

I have a few thoughts on the proposal:

• The rule would report code like this, where mutable state is used as an implementation detail (e.g. for caching) without being exposed as part of the module’s API.

  let foo;
  
  export function getFoo() {
      if (!foo) {
          // lazy load
          foo = expensiveComputation();
      }
      return foo;
  }
  

  I agree that it’s almost always a bad idea to expose global mutable state. I don’t think it’s necessarily a problem to have global mutable state, provided that the state is an implementation detail and the module’s API acts as if it were immutable. The proposed rule would report the latter, even if the goal is to prevent the former.

• It’s worth noting that module-scoped variables are not the only way to accidentally expose mutable state. For example, a user could modify a property of a module-scoped variable, and it wouldn’t be caught by this rule.

• Bikeshed: I’m not a fan of the name no-implicit-module. I assume no-implicit-module was a modification of the existing no-implicit-global rule, but I don’t think that wording makes sense (there isn’t anything implicit going on, and the module itself isn’t the problem.) Maybe something like no-mutable-module-bindings would be better.

[thuba]

Ok, I understand, thank you for explanation!