-
-
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
Implement new rule: no-internal-modules #485
Implement new rule: no-internal-modules #485
Conversation
Ah, sounds cool. Normally I'd like to see an issue with a proposal first, but a PR makes for a very explicit proposal. 😄 Adding Need to get @jfmengels' thoughts on this, too. @sindresorhus, I think you may have thoughts an feelings on something like this, too, if you're willing to take the time to evaluate and share. (no worries if not!) Also, I'm not sure I love |
Thanks @spalger!
Same here, but this sounds interesting anyway :) Not sure about the rule name either. I like the idea of shallow, but starting with no- is more ESLint like. I do think that ../foo/index should be allowed though. Not very constructive, but gotta go sorry ^^' |
Sorry :) Happy to see it go in, but not married to the idea if y'all would prefer a different direction entirely.
I like the idea, but one thing I don't want to imply is that the rule is missing a
I would love to replace minimatch with another solution. Especially if it allow removing the path-separator-normalization dance. The initial implementation followed the lead of |
Could you refactor to use |
glob is about finding files on the file system that match the pattern, not about checking if a known path (the resolved path of an import statement) matches a pattern. minimatch is the matching library used by glob though, so the user experience should be exactly the same. If you think it's necessary I can probably extract the minimatch pattern used by glob, but I think it would make more sense to depend on minimatch directly. |
Ah, got it. As you can tell, I'm not very familiar with either. Just reminded me of an old ESLint issue about gitignore vs eslintignore. That makes sense, now. |
|
||
## Rule Details | ||
|
||
This rule has one option, `allow` which is an array of minimatch patterns to identify directories whose children can be imported explicitly. |
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 you make minimatch patterns
a link that links to documentation about minimatch patterns?
This looks pretty good to me. I still think that |
@jfmengels In my eyes, the spirit of the rule is that the consumer of a module shouldn't be concerned with the implementation of the module. This includes where the entry point is. If the module is using an |
@jfmengels I updated the rule so that Because of this you could use |
return !!find(allowRegexps, re => re.test(importPath)) | ||
} | ||
|
||
// minimatch patterns are expected to use / path seperators, like 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.
nitpick: seperators --> separators 😅
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 spell that word wrong everywhere, all the time, I think I need to setup autohotkey just for it.
Some nitpicks/code style improvements from me, but looks good to me otherwise :) |
I get the reasoning of not wanting to duplicate the plugin name, but I find (PS : Bikeshedding is hard :D) |
@jfmengels I think that's a reasonable concern in general, but in this case it's not obvious to me what incorrect behavior that name would imply. i.e. what would you expect not to be allowed, given This rule is pretty restrictive in that way. Seems like a fair characterization. |
Well, I wouldn't expect much to be allowed I guess if this rule forbid internal modules altogether :p You're right that naming and functionality-wise it's very close to Let's put it this way: When I read the rule name, I read |
I guess I want to err on the side of being concise, because absolutely no internal modules ever would be a wild world in which to try to code (and lint!). |
Ok, let's go with that then. |
You would need to add |
…to implement/rule/no-reaching-in
Thanks for merging from master! Could you go ahead and rename it to |
Whoops, got distracted previously I guess 😄 . Updated! |
1 similar comment
@@ -0,0 +1,2 @@ | |||
require('babel-register') | |||
require('./tests/src/rules/no-internal-modules.js') |
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.
what is this file? looks like an impromptu describe.only
?
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.
Whoops :)
Apart from @benmosher's comment, this looks good to me. Thanks a lot @spalger! 😄 |
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.
LGTM
(sorry, just wanted to use the new GitHub approval system :p)
lol @jfmengels, me too. @spalger: looks great! thanks for working with us! |
🎉 🎉 🎉 🎉 🎉 |
Hey, once again: Thanks a lot @spalger, this is awesome! |
See doc page for details