New: Add no-restricted-exports rule (fixes #10428)

[mdjermanovic]

What is the purpose of this pull request? (put an "X" next to item)

[X] New rule #10428

Examples of incorrect code for this rule:

/*eslint no-restricted-exports: ["error", ["foo", "bar", "Baz", "a", "b", "c", "d"]]*/

export const foo = 1;

export function bar() {}

export class Baz {}

const a = {};
export { a };

function someFunction() {}
export { someFunction as b };

export { c } from 'some_module';

export { something as d } from 'some_module';

What changes did you make? (Give an overview)

New rule no-restricted-exports

Is there anything you'd like reviewers to focus on?

• configuration

Configuration is ["error", ["foo", "bar"]] instead of ["error", "foo", "bar"]

This might be a better choice as it's clear that "error" isn't a restricted name, but it's different from other similar rules. Is it okay? There was a discussion about this in #11331.

• custom messages

This wasn't mentioned in the issue thread, should the rule support custom messages for configured restricted names?

• reported nodes

The rule always reports Identifier nodes, rather than the declaration nodes (because a declaration can export more names, including the valid ones).

• export default

Configured "default" doesn't disallow export default (although it does export "default" name). Is it okay? There is a section in the documentation about this.

• export * from 'some_module'

This can export restricted names, but it's out of scope for this rule and noted in the Known Limitations section.

• documentation

I'm not sure what to note as a typical use case in the very first section (maybe nothing?).

[ilyavolodin]

The code looks fine, and I think all of the assumptions are valid. However, I notice more and more people do not want to use default exports, because named exports are a lot more descriptive. It would be nice to add an option to this rule to disallow default exports. But that could be done in a separate PR, I guess.

[mdjermanovic]

👍 to add the option in a separate PR.

Though, it might be good to already think about how the option fits the current design.

["error", ["default"]] disallows export { foo as default }, but allows export default foo. That's already implemented in this PR.

The new boolean option would disallow just export default syntax, but allow default exports via named export declarations?

For instance, ["error", [""], { disallowExportDefault: true }] disallows export default foo, but allows export { foo as default }.

["error", ["default"], { disallowExportDefault: true }] disallows any forms of default exports.

[kaicataldo]

While ["error", ["default"], { disallowExportDefault: true }] makes sense given what the rule does, it certainly is verbose and I do worry that it would be confusing to a new user.

Alternatively, could we replace the first configuration option with an object and do something like the following?

["error", { 
  restrictedExports: ["default"],
  disallowExportDefault: true
}]

[mdjermanovic]

Alternatively, could we replace the first configuration option with an object and do something like the following?

["error", { 
  restrictedExports: ["default"],
  disallowExportDefault: true
}]

This looks better to me!

Maybe restrictedNamedExports to make it more clear that it doesn't affect export default?

Given that is seems (based on votes) that the new option will be added at some point, I'm 👍 to change the initial configuration now.

@ilyavolodin would you agree with this change? (asking because you already approved the current version)

[kaicataldo]

Maybe restrictedNamedExports to make it more clear that it doesn't affect export default?

Sounds good to me 👍

[mdjermanovic]

Configuration is now changed from ["error", ["foo", "bar"]] to:

["error", { restrictedNamedExports: ["foo", "bar"] }]

(if that isn't okay, I'll revert the change)

[kaicataldo]

LGTM! Thanks for the comprehensive test suite.