-
Notifications
You must be signed in to change notification settings - Fork 144
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
Check for mozIndexedDB; close #15 #44
Conversation
4496127
to
dbfd899
Compare
I think this is ready for r? now. |
var code = 'var myDatabase = indexeddb || mozIndexedDB;'; | ||
var jsScanner = new JavaScriptScanner(code, 'badcode.js'); | ||
|
||
jsScanner.scan() |
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.
If you return a promise in a test you don't need to use done()
it's actually quite useful as this will expose issues where the code misses returning a promise too.
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.
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.
Yeah it's handy, I only found out about this recently too.
Looks pretty good overall - just a few things that need addressing. Would be good to fix up the returning promises in the tests that feature promise-based apis rather than using It seems it's important to understand any limitations of eslint can a test be easily bypassed through obfuscation via concatenated propnames. Maybe FreddyB has seen good ways to handle that? Also that require / import question you raised is of a similar nature. There's a couple of missing tests, e.g. just a basic one for the util and also I think we need some to make sure errors are being handled should eslint blow-up or the js-validator blow-up in the iteration over the js files in the xpi tests. The rest are minor nits. |
Give me shout if you want to chat over any of these bits. Some of it we might want to move to future bugs - and that's fine to do. We just need to be careful we don't end up with a huge list of things that mean that eslint for validation is easily bypassed. |
@@ -1,6 +1,10 @@ | |||
export const DEFLATE_COMPRESSION = 8; | |||
export const NO_COMPRESSION = 0; | |||
|
|||
export const SEVERITY_ERROR = 2; |
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.
Could this not use VALIDATION_* instead. Seems it might get confusing to have uses of similar but different constants. I'm easily confused :)
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.
Yeah, that's better. I used severity as it's what ESLint uses internally, but I didn't like it either. VALIDATION_
it is! 😄
271afd5
to
d75b539
Compare
Hey there, updated the PR. Should have fixed everything. Let me know if that test in validator is still too much and we can take it out, but it should be less brittle now. I liked testing against an actual file, but if it's not discrete enough let me know. |
addToCollector(message) { | ||
var messageType = message.severity.charAt(0).toUpperCase() + | ||
message.severity.slice(1); | ||
console.log(message); |
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.
Could probably remove this - though at some point it would be nice to have some configurable logging - we should add an issue to add something with debug levels.
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.
Oops, yes, this is totally unintentional.
Nice one! Couple of minor nits left but looks good r+wc. |
Thanks! All the nits are fixed now; gonna squash a few commits then merge it. |
ec0eb3e
to
103ad02
Compare
5a475cb
to
e8014c2
Compare
Check for mozIndexedDB; close #15
This adds support for custom ESLint rules and tests for the existence of
mozIndexedDB
.It adds a
getFileAsString()
method to theXpi
class so we can load entire files into memory to pass to linters like ESLint, which needs the entire file and can't deal with streams. As discussed earlier on IRC, we might not end up passing streams around much when maybe checks need the full context of a file.