New rule: Prevent/warn about the usage of window in favor of self.

[dryajov]

Please describe what the rule should do:
Prevent/warn about the usage of window in favor of self, with self being a proxy to the current global context and should work across all environments in the browser.

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

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

• Enforces portability across non DOM environments

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

// should warn/error on use of window and suggest usage of self instead
if (window.crypto && window.crypto.getRandomValues) {
    // Modern browsers
    Rand.prototype._rand = function _rand(n) {
      var arr = new Uint8Array(n);
      window.crypto.getRandomValues(arr);
      return arr;
    };
  } else if (window.msCrypto && window.msCrypto.getRandomValues) {
    // IE
    Rand.prototype._rand = function _rand(n) {
      var arr = new Uint8Array(n);
      window.msCrypto.getRandomValues(arr);
      return arr;
    };
  } else {
    // Old junk
    Rand.prototype._rand = function() {
      throw new Error('Not implemented yet');
    };
  }

===============

// should not warn/error on the usage of self
if (self.crypto && self.crypto.getRandomValues) {
    // Modern browsers
    Rand.prototype._rand = function _rand(n) {
      var arr = new Uint8Array(n);
      self.crypto.getRandomValues(arr);
      return arr;
    };
  } else if (self.msCrypto && self.msCrypto.getRandomValues) {
    // IE
    Rand.prototype._rand = function _rand(n) {
      var arr = new Uint8Array(n);
      self.msCrypto.getRandomValues(arr);
      return arr;
    };
  } else {
    // Old junk
    Rand.prototype._rand = function() {
      throw new Error('Not implemented yet');
    };
  }

Why should this rule be included in ESLint (instead of a plugin)?
There is a large surface of non DOM related APIs being added to browsers that work across DOM and non DOM (WebWorker/ServiceWorker) environments. In many cases window is used as a reference to the global context to test for the presence of those features which makes it non-portable across non DOM environments. As we move towards browsers with more and more capabilities beyond the DOM, this is going to become more of a problem. An eslint rule should alleviate the transition and enforce a very important best practice, having it as a plugin would mean less penetration and adoption across the board.

[not-an-aardvark]

Thanks for the rule suggestion. To continue the Gitter discussion that led to this issue, you can already use no-restricted-globals to enforce this in the general case, so I don't think it's a good idea to have an entirely new rule just for window versus self. I think enhancing no-restricted-globals to allow custom error messages would be a good idea, though.

[dryajov]

I'm entirely for that and indeed it seems to be the best course of action. After all the intent here is to enforce a best practice, if this enhancement would allow for that I see no reason for not doing it, plus the obvious added benefit is that it can be used in other similar scenarios. 👍

Should this issue be kept open to move this effort forward or would a new one be required?

[platinumazure]

@dryajov If you wouldn't mind editing the first post and title to conform with your new proposal, we can keep using this issue. Thanks! 😄

[platinumazure]

@dryajov I do apologize, I wasn't clear. I'd love to see a proposal for a rule change so that no-restricted-globals can accept messages. Maybe it could be structured similar to no-restricted-properties. That way you get your custom message without us needing to support another rule. 😄

Note that you can also implement a specific no-window rule as a plugin rule, if you want. I just don't see it entering ESLint core.

Oops, I thought the issue was already edited, but it hasn't been. 😄

[dryajov]

@platinumazure , I think there is no confusion, im going to enhance no-restricted-globals to take a custom message for globals, which is what has been suggested. I just haven't gotten around changing this issue, will try to get to it today. :)

[platinumazure]

@dryajov Haha, that's my mistake then, I thought you had already edited the issue. Sorry about that!

[dryajov]

closing in favor of #8315