Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not fail yarn linc for ignored file warning (#11615) #11641

Merged
merged 6 commits into from Nov 28, 2017

Conversation

HeroProtagonist
Copy link
Contributor

Resolves #11615

Problem
This error happens because by default eslint ignores dotfiles. The yarn linc command can supply dotfiles like .eslintrc.js causing this error because of the mismatch between the ignore patterns and what is being given as lint input. This eslint thread talks about this issue with this PR resolving it.

Solution
Hidden files will now be linted, but not hidden folders. As of now the only hidden .js file seems to be the .eslintrc.js, but this will prevent this from happening if any are added in the future. As a bonus the rc file will be linted going forward.

Happy Thanksgiving! 馃

@facebook-github-bot
Copy link

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

@facebook-github-bot
Copy link

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

@gaearon
Copy link
Collaborator

gaearon commented Nov 25, 2017

The yarn linc command can supply dotfiles like .eslintrc.js causing this error because of the mismatch between the ignore patterns and what is being given as lint input.

Hmm. What if the changed files are in an ESLint-ignored folder? I guess in that case we'd still see this issue, wouldn't we?

I think the right fix for this would have been to disable this particular rule. At least when running on changed files.

@gaearon
Copy link
Collaborator

gaearon commented Nov 25, 2017

Or maybe we should still exit with the zero code if the only failing rule is this one? I think printing this information is still useful.

Assuming my analysis in #11641 (comment) is right. If it's not let me know!

@HeroProtagonist
Copy link
Contributor Author

What if the changed files are in an ESLint-ignored folder? I guess in that case we'd still see this issue, wouldn't we?

It would display this very similar issue "File ignored because of a matching ignore pattern. Use \"--no-ignore\" to override." I tested this by making some changes in scripts/bench/benchmarks directory.

I think the right fix for this would have been to disable this particular rule.

From my looking into eslint, it seems this cannot be disabled because it is not so much a rule as it is eslint being told one thing and then supplied another.

Or maybe we should still exit with the zero code if the only failing rule is this one?

This is what the code now reflects. I made a function that will validate the warnings from the eslint report. If all the warnings contain the File ignored text the warnings will be displayed as before, but the lint will now pass.

@gaearon
Copy link
Collaborator

gaearon commented Nov 27, 2017

Sorry--do you mind rebasing on top of master? Thanks!

@HeroProtagonist HeroProtagonist changed the title Add lint rule to ignore default handling of hidden files Do not fail yarn linc for ignored file warning (#11615) Nov 27, 2017
@HeroProtagonist
Copy link
Contributor Author

Done!

const report = cli.executeOnFiles(filePatterns);
const formattedResults = formatter(report.results);
console.log(formattedResults);
return report;
}

function validWarnings(report) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's move this to where it's used?
Also let's rename to something like getSourceCodeWarnings.

In fact I would just inline this logic in the script that uses it, and add a comment explaining why it exists.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes reflect this. Do you prefer to have function declaration vs definition?

@gaearon gaearon merged commit 7788bcd into facebook:master Nov 28, 2017
@gaearon
Copy link
Collaborator

gaearon commented Nov 28, 2017

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants