Bugzilla

There's a few things I would like to do for Lintpref before it can start examining more pref files:

1. Have Lintpref get its file paths from the yml file rather than statically checking `all.js` against `StaticPrefList.yaml`. This is the behavior reflected in other linters, and I didn't worry about it at the time since we were only looking at `all.js`. In order to write tests for the linter and expand its usage to more files, it's better to get file paths from `lintpref.yml`.

2. Improve parsing of `all.js` and other associated prefs files. Right now it just trusts that the pattern of prefs is regular enough to pull the names out, but it could do this more elegantly. It looked at first that `read_prefs`[1] was the right function to use to do this, but there's some file format mismatches that causes it to have read errors. There may be another function in the library to do this. Or, I can just write a similar function to `read_prefs` as a part of lintpref.

3. Detect `value` mismatches in duplicates. This is going to require a lot of consideration - right now, `value` is not considered and so we don't do any preprocessing steps. there are a few ways to address this, including storing *all* of the possible values found in the `value` field against each pref, and checking them against the *.js files' values as a list. This is useful for files like `mobile.js` where there will be a lot of prefs that are overwritten with different values. When there is a value mismatch, the pref can either be ignored completely (since it'll be overwriting the static pref with the new value) or warned as a potential duplicate instead of reporting an error.

4. Write test files for Lintpref. The linters now have tests, and lintpref should have tests too. Before, it wasn't possible to really create a test case since it was reading `all.js` exclusively. With the changes in part 1 it will be possible to write tests.

There's a few things I would like to do for Lintpref before it can start examining more pref files:

1. Have Lintpref get its file paths from the yml file rather than statically checking `all.js` against `StaticPrefList.yaml`. This is the behavior reflected in other linters, and I didn't worry about it at the time since we were only looking at `all.js`. In order to write tests for the linter and expand its usage to more files, it's better to get file paths from `lintpref.yml`.

2. Improve parsing of `all.js` and other associated prefs files. Right now it just trusts that the pattern of prefs is regular enough to pull the names out, but it could do this more elegantly. It looked at first that `Preferences.read_prefs` was the right function to use to do this, but there's some file format mismatches that causes it to have read errors. There may be another function in the library to do this. Or, I can just write a similar function that reads in prefs as a part of lintpref.

3. Detect `value` mismatches in duplicates. This is going to require a lot of consideration - right now, `value` is not considered and so we don't do any preprocessing steps. there are a few ways to address this, including storing *all* of the possible values found in the `value` field against each pref, and checking them against the *.js files' values as a list. This is useful for files like `mobile.js` where there will be a lot of prefs that are overwritten with different values. When there is a value mismatch, the pref can either be ignored completely (since it'll be overwriting the static pref with the new value) or warned as a potential duplicate instead of reporting an error.

4. Write test files for Lintpref. The linters now have tests, and lintpref should have tests too. Before, it wasn't possible to really create a test case since it was reading `all.js` exclusively. With the changes in part 1 it will be possible to write tests.