-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add allow-require
option to no-commonjs
rule
#880
Conversation
docs/rules/no-commonjs.md
Outdated
If `allow-require` is provided as an option, `require` calls are valid: | ||
|
||
```js | ||
/*eslint no-commonjs: [2, "allow-require"]*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use an object schema instead, so it's extensible - like { allowRequire: true, allowPrimitiveModules: true }
.
We should move away from string schemas (but continue to support the existing ones, ofc)
|
||
but `module.exports` is reported as usual. | ||
|
||
This is useful for conditional requires. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you have this rule enabled, wouldn't you use import()
for conditionals?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, you could. I guess it's for compatibility only then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I just looked though some babel-plugin-dynamic-import-node tests, the new dynamic import
is async and thus is not a drop-in replacement for require
. So I guess adding a hint like this would suffice:
This is useful for conditional requires. If you don't rely on synchronous module loading, check out dynamic import.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True enough; your suggestion is a good addition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was my knee jerk reaction as well, but I think the sync argument tracks.
6fbd7b7
to
759efd4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a schema
to this rule so eslint can validate it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks great!
src/rules/no-commonjs.js
Outdated
|
||
schema: { | ||
anyOf: [ | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this first anyOf item can just be schemaString
by itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, options are always an array of things.
4 similar comments
I'm so waiting for this to release. Is there anything else to do for me? |
@futpib i'd like @benmosher or @jfmengels to review it prior to merging. |
Hi @futpib, sorry it has been literally forever since you submitted this and I'm finally getting back to it. 😅 I just upgraded this to semver-major because it changes the options on this rule. If you'd like to get it merged into the next 2.x release, can you make the options match the existing rule? i.e. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see my note in the main PR conversation thread, but tl;dr: extend the existing allow-primitive-modules
enum to be set as allow-requires
.
I think it's okay--or even ideal--if they are mutually exclusive, as IIRC enabling both would turn off the rule and is therefore a nonsense config state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nvm, I totally read this wrong and you are fine 😅
I misread the new tests as changes, but you left the existing tests in place so obviously it's semver-minor, my bad!
@benmosher still got semver-major label though |
78bc94b
to
c438d3e
Compare
This fixes #548