-
-
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 rule 'no-self-import' #727
Conversation
src/rules/no-self-import.js
Outdated
if (filePath === resolvedPath) { | ||
context.report({ | ||
node, | ||
// TODO: check in about message, should it print the name of the module 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.
yes, i think it should - it's much more helpful that way. Ideally, it'd include the path to the file, and, if different, the path used in the import
statement.
tests/src/rules/no-self-import.js
Outdated
|
||
ruleTester.run('no-self-import', rule, { | ||
valid: [ | ||
test({ code: 'import _ from "lodash"'}), |
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.
how can any of these valid examples be deemed such without a filename to test against?
It's probably good to keep all of these, to ensure that when there's no filename (like stdin input), the rule bails out, but these should include a filename 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.
Thanks, that makes sense, I don't totally grok the testing setup yet. I'll add that.
import isStaticRequire from '../core/staticRequire' | ||
|
||
function isImportingSelf(context, node, requireName) { | ||
const filePath = context.getFilename() |
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 happens when the input is from stdin, and thus there's no filename?
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.
Good catch! When that happens, filePath
will equal '<text>
. In some other plugin, we've handled it like: https://github.com/sindresorhus/eslint-plugin-unicorn/blob/master/rules/filename-case.js#L71-L73
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.
That seems totally reasonable - it might also be useful to create a generic way to tag rules as "does not apply when the file is from stdin"
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 have actually never used the --stdin
option and don't know the uses for 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.
I didn't even know that was a thing you could do.
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 use it all the time when providing reproduction steps for eslint bugs :-p
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.
last I knew, Sublime uses --stdin
, but with --stdin-filename
(or something like that) to fake in the filename
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 a lot @giodamelio, that was quick! 😄
Is there any special way the error message should be written?
We don't have a convention for error message in this plugin AFAIK. From what I see at a glance, most error messages end with a period (with some exceptions, but you might as well add it, I usually add it in other rules plugins) and start with an uppercase letter. As far as the content of the message, the clearer the better, but it should stay relatively short. The current message looks good to me, but if someone finds something better, 👍
Is it best practices to dynamically generate error messages based on the context?
If it helps the user understand and fix the error, sure.
Tests-wise, could you add the following cases:
valid:
- filename is
bar.js
, code is importing./bar/index.js
- filename is
bar/index.js
, code is importing./bar
invalid: - filename is
bar/index.js
, code is importing../bar/
- filename is
index.js
, code is importing./
- filename is
index.js
, code is importing.
- filename is
index.js
, code is importing././././
- filename is
bar.js
, code is importing./bar.js
And more if you think of more (odd) cases.
src/rules/no-self-import.js
Outdated
context.report({ | ||
node, | ||
// TODO: check in about message, should it print the name of the module itself | ||
message: 'Module imports 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.
should it print the name of the module itself
I think there is no need. If they see the error in the editor, they will already have the file open and see which file the error is for. If they see it in the terminal or a CI environment's terminal, ESLint will display the location of the file it is in.
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.
That's true - but because resolution is being applied, it might not be immediately apparent which import path is pointing back to the file.
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.
ESLint will tell you on what line the import is, and in the editor, it will put red squiggly lines under the import statement / require call. That sounds sufficient to me, especially since (IMO) having the whole path to the file in the error message would probably make the error harder to read.
src/rules/no-self-import.js
Outdated
description: 'Prohibits a file from importing itself', | ||
recommended: true, | ||
}, | ||
fixable: 'code', |
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.
Remove this line as the rule is not fixable.
That should take care of the changes you guys requested. |
2 similar comments
1 similar comment
That should cover the changelog and docs. |
I think the AppVeyor build might have failed because I pushed a second commit while the first one was still running, I saw that happen earlier. I didn't change any code in these last two commits, so it shouldn't have broken. |
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.
Yep those files are needed. I just added a comment in them explaining. |
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.
Yep those files are needed. I just added a comment in them explaining.
Perfect!
I added a few commits to fix some typos (don't force push over it!)
This LGTM! I'm leaving some time for someone else to review.
Oh, and no need for squashing it yourself, we can do it directly now with GitHub.
Again, thanks a lot @giodamelio!
Sounds good to me. |
(heads up tho, if you squash directly on github you actually lose the link to the git log for the PR - it's far better to rebase/squash on the command line before clicking the button on github) |
1 similar comment
Oh my god, @coveralls bot is getting a bit annoying. |
@ljharb I'm sorry, what git log are you talking about? Sorry about the delay @giodamelio! |
I think he meant when you squash on the cli you can include the commit messages from all the commits in the body of the squashed commit. I can squash it for you if you want, but I don't really mind losing the messages. |
Hmm, this is what I'd get if I were to squash it from GitHub (I have the option to edit if I want to):
So I'm not sure what logs would be lost. |
Oh, I didn't think Github could do that. You might as well do it on your end then, the squash was giving me a bit of trouble and I would rather Github take care of it then me borking something. |
@jfmengels i'm talking about when you fetch the In other words, it's not just the commit messages. I'm content to do the squash for you, if that's necessary? |
@jfmengels also, if you note the text "Add more commits by pushing to the feature-no-self-import branch on giodamelio/eslint-plugin-import." - PRs now by default have the box checked that allows maintainers to push branches directly to the fork - so in fact you can directly update this PR's branch, which then reruns the tests, before actually doing the merge. |
e695506
to
0ea3d80
Compare
I've just done the rebase and force pushed it to the fork. Once tests have passed, please feel free to do a normal merge with a merge commit. |
Not sure exactly why the AppVeyor build failed, I don't think it handled the rebase well. |
1 similar comment
@benmosher @jfmengels I just wanted to ping you guys and see about getting this merged and inquire about a new release, that could hopefully include this. |
@giodamelio it'll need another rebase to remove the merge commit (the "update branch" button doesn't help) |
Yep, I shouldn't have used the "fix conflicts" button. Only causes me more issues 😑. Fix incoming. |
6dc8a86
to
fdb7823
Compare
Should be good to go. |
Hey guys, I totally forgot about this pull. I think it should be ready to go still. |
@giodamelio would you rebase it on the command line, and we do need to figure out why the tests are failing |
(it's possible that tests are failing on master, tho) |
df1d5cd
to
be5b52d
Compare
Took care of the rebase; tests are passing now. |
Thanks, I totally forgot about this again :). Merged after almost a year. :) |
Stops a file from importing itself. See #449 for details.
Progress:
A few questions
Closes #449. Fixes #447.