Closed chrisvltn closed 4 days ago
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?
@Tanujkanti4441 great idea. A rule to allow only certain named exports would also fit well to solve the problem :)
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
.
+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.
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)?
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. :+1:
Marking as accepted.
@chrisvltn would you like to submit a pull request?
Sure 👍 thanks for the quick discussion. I'll find some time soon to open a PR
Closed by #18431
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
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
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.