Rule Change: no-restricted-exports to accept Regex patterns

[chrisvltn]

What rule do you want to change?

no-restricted-exports

What change do you want to make?

Generate more warnings

How do you think the change should be implemented?

Other

Example code

/*eslint no-restricted-exports: ["error", {
    "restrictedNamedExports": ["/^(?!foo)(?!bar).+$/g"]
}]*/

// Success
export const foo = 1;
export function bar() {return 2;}

// Error
const a = {};
export { a };

What does the rule currently do for this code?

The rule currently accepts only hardcoded strings as restrictions

What will the rule do after it's changed?

The rule will accept also regex patterns as name restrictions

Participation

• I am willing to submit a pull request to implement this change.

Additional comments

Remix framework recommends not exporting anything other than their main route functions in route files, otherwise HMR won't work. Sadly, there is no way to enforce that with ESLint currently.

[Tanujkanti4441]

Hi @chrisvltn, thanks for the issue.

I think this is a good idea to add regex for no-restricted-exports rule but according to your specification we can also think about an option that would contain only those export names that are allowed and other will be restricted.

@eslint/eslint-team, should we consider this?

[chrisvltn]

@Tanujkanti4441 great idea. A rule to allow only certain named exports would also fit well to solve the problem :)

[nzakas]

I don't feel strongly either way, but if we do make this change, I think we should match how regexes are defined in no-restricted-imports.

[JoshuaKGoldberg]

+1 in general to this request and keeping consistent with equivalent rules. Especially when there's already mirroring in the rule name: e.g. no-restricted-(exports|imports).

For specifically mirroring no-restricted-imports, is there a need to mirror paths? I'd think everything would be doable with patterns that use ^ and/or $ to delineate full matchers.

[mdjermanovic]

I don't see much similarity between these two rules, despite the similar names.

no-restricted-imports is about disallowing the use of existing modules by specifying string paths or .gitignore-style patterns that match the import source (e.g., "mod" in import { foo } from "mod"). Optionally, only certain names (foo) can be disallowed by additionally specifying importNames or importNamePattern.

no-restricted-exports is about naming new exports. There's no import source to which paths/patterns would correspond.

We could add an option restrictedNamedExportsPattern (a string that will be used as a regex pattern)?

[nzakas]

We could add an option restrictedNamedExportsPattern (a string that will be used as a regex pattern)?

I suppose that does go along with the existing restrictedNamedExports option. 👍

Marking as accepted.

@chrisvltn would you like to submit a pull request?

[chrisvltn]

Sure 👍 thanks for the quick discussion. I'll find some time soon to open a PR