New rule: no-restricted-exports

(Continuation of #9180)

Please describe what the rule should do: Currently, if you get an ES Module namespace object with import * as foo from 'path', there’s a hazard: that module might have a named function export of “then”, which means Promise.resolve(foo) or await foo won’t do what you expect.

This is also particularly hazardous in the current stage 3 import() proposal, so the need will increase in the future - but the need is present now, based on ES2015.

I’d like to provide a rule that defaults to blocking named exports named “then”, but could also be configured for any arbitrary list of restricted export names (including “default”).

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:

export function then() {
  return "foo";
}

function v() {return 123;}
export {v as then};

Why should this rule be included in ESLint (instead of a plugin)? Module namespace objects are frozen - they’re supposed to conceptually represent a static, pre-runtime-determined, representation of an ES Module. It’s very very surprising that a module could suddenly become thenable, breaking its consumers, or suddenly become not thenable, also breaking its consumers.

This rule will help prevent problematic exports in the first place by warning when they are created.

[platinumazure]

I don’t see why we couldn’t do no-restricted-exports. I will champion this rule proposal.

[kaicataldo]

This has now been accepted.