-
Notifications
You must be signed in to change notification settings - Fork 149
Fix RESERVED_FILENAME message construction. #2617
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
Conversation
e97c116
to
ae061f6
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.
Looks like the tests are failing quite heavily.
}; | ||
} | ||
|
||
export const MANIFEST_ICON_NOT_FOUND = 'MANIFEST_ICON_NOT_FOUND'; |
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 these constants are used in tests so they should probably continue to be used.
Ah I think I see it now looking further at the code, this is adding a test for the description which is causing the newly added rule to break. |
ae061f6
to
a06094c
Compare
In 3888a7d I introduced reserved filename scanning and forgot to define a `description` property on the `RESERVED_FILENAME` message. The `description` is needed to be properly exposable to the JSON and text exports.
a06094c
to
df2e450
Compare
I re-did the PR completely in df2e450 and made the diff a bit more manageable, especially given it's a regression fix only which should be cherry-picked into this weeks release. |
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.
r+wc and assuming tests are green
tests/unit/scanners/test.filename.js
Outdated
expect(linterMessages.length).toEqual(1); | ||
expect(linterMessages[0].code).toEqual(messages.RESERVED_FILENAME.code); | ||
expect(linterMessages[0].message).toEqual('Reserved filename found.'); | ||
expect(linterMessages[0].description.startsWith('Files whose names are reserved')).toEqual(true) |
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.
These two lines could directly assert against RESERVED_FILENAME.message
and RESERVED_FILENAME.description
couldn't they?
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.
Then I actually wouldn't match/notice the undefined
description
property which is what I'm after here.
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.
Ah yes, good point. As and when the general test for descriptions can cover checking for undefined
, this could then be updated, but this gets the necessary fix in which is what you're aiming for right now 👍
In 3888a7d I introduced reserved
filename scanning and forgot to define a
description
property on theRESERVED_FILENAME
message.The
description
is needed to be properly exposable to the JSON andtext exports.