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’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

Merged
merged 4 commits into from
Dec 11, 2018

Conversation

freaktechnik
Copy link
Contributor

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.

@@ -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 |
Copy link
Contributor Author

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...

Copy link
Contributor

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 🤷‍♂️

@freaktechnik
Copy link
Contributor Author

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.

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.

@EnTeQuAk EnTeQuAk self-requested a review November 27, 2018 11:09
Copy link
Contributor

@EnTeQuAk EnTeQuAk left a 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 |
Copy link
Contributor

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 🤷‍♂️

}

export const PERMISSION_FIREFOX_UNSUPPORTED_BY_MIN_VERSION =
'èERMISSION_FIREFOX_UNSUPPORTED_BY_MIN_VERSION';
Copy link
Contributor

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

src/utils.js Show resolved Hide resolved
@freaktechnik
Copy link
Contributor Author

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.

The reason I had split them is so they are different reported messages. Since some people may not care about android incompatibility.

@EnTeQuAk
Copy link
Contributor

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?

@freaktechnik
Copy link
Contributor Author

freaktechnik commented Nov 27, 2018

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.

@EnTeQuAk
Copy link
Contributor

From what I understand the eslint rules are mapped to codes here: /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?

@freaktechnik
Copy link
Contributor Author

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.

@EnTeQuAk
Copy link
Contributor

EnTeQuAk commented Nov 28, 2018

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 utils.js so it's not the worst place to start. At some point, we may want a specific rule_helpers.js (or src/rules/utils.js which might be better) but I think utils.js might be fine. cc @rpl for a second opinion

@ExE-Boss
Copy link

I’d personally go with src/rules/utils.js.

@EnTeQuAk
Copy link
Contributor

EnTeQuAk commented Dec 5, 2018

@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 🙈

@freaktechnik
Copy link
Contributor Author

I do have the time though I wasn't expecting much activity this week...

@freaktechnik freaktechnik force-pushed the version-check branch 2 times, most recently from 13e604a to 9dc16e7 Compare December 5, 2018 20:27
@freaktechnik
Copy link
Contributor Author

freaktechnik commented Dec 5, 2018

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).

@EnTeQuAk
Copy link
Contributor

(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)

Copy link
Contributor

@EnTeQuAk EnTeQuAk left a 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.

@EnTeQuAk EnTeQuAk merged commit fc1ddbc into mozilla:master Dec 11, 2018
EnTeQuAk added a commit that referenced this pull request Dec 11, 2018
* Pin dependencies to fixed version again
* Don't ignore files and folders with a leading dot. (#2316)
* Detect API and manifest key incompatibilities with strict_min_version (#1493) (#2290)
* Move internal scripts to separate folder (#2309)
* Various dependency updates
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants