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.

Sign up for GitHub

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

Fix nits/typos from "Allow specs to be represented by a simple string" #4

Merged
merged 1 commit into from
Jan 31, 2020
Merged

Fix nits/typos from "Allow specs to be represented by a simple string" #4

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions lint.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,9 +7,9 @@ const ajv = new Ajv();

// When an entry is invalid, the schema validator returns one error for each
// "oneOf" option and one error on overall "oneOf" problem. This is confusing
// for humans. the following function improves the error being returned.
// for humans. The following function improves the error being returned.
const clarifyErrors = errors => {
if (!errors || (errors.length < 2)) {
if (!errors || errors.length < 2) {
Copy link
Member

Choose a reason for hiding this comment

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

Do you have favorite code guidelines?

I don't mind either syntax, just wondering if this is more gut feeling or if you're following a specific rule here. For instance, if I run ESLint with no-extra-parens, it's going to report this line but it's also going to report other if lines below where parentheses could also be dropped.

Copy link
Member Author

Choose a reason for hiding this comment

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

My favorite style is any style that can be enforced and autofixed by tooling. These parens just seemed clearly unnecessary to me, but if a style rule added them back I wouldn’t mind.

return errors;
}

Expand All @@ -23,8 +23,8 @@ const clarifyErrors = errors => {
}

// Otherwise, if second error is a type error for second oneOf choice,
// it means the itme is actually a string that represents an invalid URL,
// which the first error should capture
// it means the item is actually a string that represents an invalid URL,
// which the first error should capture.
if (errors[1].schemaPath === "#/items/oneOf/1/type") {
return [errors[0]];
}
Expand Down Expand Up @@ -128,4 +128,4 @@ else {
// Code imported to another JS module, export lint functions
module.exports.lintStr = lintStr;
module.exports.lint = lint;
}
}
2 changes: 1 addition & 1 deletion test/lint.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -83,4 +83,4 @@ describe("Linter", () => {
/^specs\[0\] should not have additional property 'invalid'$/);
});
});
});
});