-
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
feat: detect API and manifest key incompatibilities with strict_min_version (#1493) #2290
Conversation
@@ -151,7 +151,7 @@ Dependencies are automatically kept up-to-date using [greenkeeper](http://greenk | |||
| npm run test-coverage-once | Runs the tests once with coverage | | |||
| npm run test-integration-linter | Runs our integration test-suite | | |||
| npm run prettier | Automatically format the whole code-base with Prettier | | |||
| npm run prettier-dev | Automatically compare and format modified source files against the master branch | | |||
| npm run prettier-dev | Automatically compare and format modified source files against the master branch | |
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.
Uh, this must be a side-effect from running prettier...
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.
Indeed it may, it's interesting that this hasn't been caught before though 🤷♂️
1003a11
to
0a3d25c
Compare
To expand on this a litte: if the linter should warn about these APIs that are marked as not supported but are in the schema, those should be separate rules/messages, since they will always apply, not matter the strict_min_version. It may also make sense to group these warnings by being able to tell the linters what applications should even be considered, this patch adds three messages for each Firefox and Firefox for Android, having general messages would add another three messages per application for general missing support of an api, manifest key or permission. Arguably those could re-use the schema warnings, however those are application independent and there's quite a big gap between Firefox and Firefox for Android in terms of API support. |
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.
Unless I'm mistaken, merging webextension-api-compat.js
and webextension-api-compat-android.js
should be perfectly possible since the only real difference is reporting and the isCompatible(..., 'firefox')
vs isCompatible(..., 'firefox_android')
call. Am I missing someting? If so, I think I'd prefer us doing so.
Anyhow, this is looking like a great start for a very bright future! Thanks a lot for tackling this. I'd like to test this more extensively probably today / tomorrow so I only left a first batch of comments.
cc @rpl on this for second pair of eyes to get this feature right.
@@ -151,7 +151,7 @@ Dependencies are automatically kept up-to-date using [greenkeeper](http://greenk | |||
| npm run test-coverage-once | Runs the tests once with coverage | | |||
| npm run test-integration-linter | Runs our integration test-suite | | |||
| npm run prettier | Automatically format the whole code-base with Prettier | | |||
| npm run prettier-dev | Automatically compare and format modified source files against the master branch | | |||
| npm run prettier-dev | Automatically compare and format modified source files against the master branch | |
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.
Indeed it may, it's interesting that this hasn't been caught before though 🤷♂️
src/messages/manifestjson.js
Outdated
} | ||
|
||
export const PERMISSION_FIREFOX_UNSUPPORTED_BY_MIN_VERSION = | ||
'èERMISSION_FIREFOX_UNSUPPORTED_BY_MIN_VERSION'; |
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 this should be PERMISSION instead of èERMISSION` I think
The reason I had split them is so they are different reported messages. Since some people may not care about android incompatibility. |
They can continue to be different messages, just being raised by the same rule instead? |
From what I understand the eslint rules are mapped to codes here: https://github.com/mozilla/addons-linter/pull/2290/files#diff-8253f5d405f99dbf63dd1804d117413fR191 If there's a way to define the code with context.report I'd of course do that. |
Eh, indeed, sorry I kinda had the wrong thing remembered… Can we maybe make most of the code in the rule a utility function and re-use it for both at least? |
Where should I move it? I'd optimally also move the common module imports of the browser compat data and the schema utils. And I wouldn't want to put that into utils.js, I don't think. |
Right now most or all utilities that are used in rules live in |
I’d personally go with |
@freaktechnik do you have the time to update the pull request and maybe resolve conflicts in package-lock? Although there may be a few more updates coming to addons-liner in the next few days 🙈 |
I do have the time though I wasn't expecting much activity this week... |
13e604a
to
9dc16e7
Compare
9dc16e7
to
576704e
Compare
Sorry for the force pushes, I rebased onto master and hopefully made the package-lock a lot less likely to not be auto mergable. (I still don't understand why NPM sometimes does the lockfile with ^ and sometimes not, I know there's a version based difference but there also seem to be env based differences). |
This also has to do with the npm version (node 8 vs node 10 have a very clear difference here, I keep forgetting which version does what though) |
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 really good now, thanks a ton for all this hard work! 💖
Let's get this going and see how it does in production.
Fixes #1493
This is a first attempt at integrating the browser-compat-data from the MDN compatibility tables with the linter.
It currently checks for manifest keys, permissions and APIs to be supported by the given
strict_min_version
in the manifest for both Firefox and Firefox for Android. All produced messages are warnings. However, no warning is shown if Firefox or Firefox for Android do not implement an API and that is documented in the compat data. This is to avoid a lot of Firefox for Android spam, plus the totally unsupported APIs should be caught by the schemas.I'm not quite happy with the amount of duplication of logic, even though it's subtly different for all cases, so improvement suggestions welcome! Further I'll happily add more tests, these are just the ones I could come up with.