pdfjs-dist

9529 Commits

1 Branch

1804 Tags

126 MiB

Tree: a7c19d9cbb

Commit Graph

Author	SHA1	Message	Date
Jonas Jenwald	2f3805efbc	Switch to using ESLint, instead of JSHint, for linting Please note that most of the necessary code adjustments were made in PR 7890. ESLint has a number of advantageous properties, compared to JSHint. Among those are: - The ability to find subtle bugs, thanks to more rules (e.g. PR 7881). - Much more customizable in general, and many rules allow fine-tuned behaviour rather than the just the on/off rules in JSHint. - Many more rules that can help developers avoid bugs, and a lot of rules that can be used to enforce a consistent coding style. The latter should be particularily useful for new contributors (and reduce the amount of stylistic review comments necessary). - The ability to easily specify exactly what rules to use/not to use, as opposed to JSHint which has a default set. Note: in future JSHint version some of the rules we depend on will be removed, according to warnings in http://jshint.com/docs/options/, so we wouldn't be able to update without losing lint coverage. - More easily disable one, or more, rules temporarily. In JSHint this requires using a numeric code, which isn't very user friendly, whereas in ESLint the rule name is simply used instead. By default there's no rules enabled in ESLint, but there are some default rule sets available. However, to prevent linting failures if we update ESLint in the future, it seemed easier to just explicitly specify what rules we want. Obviously this makes the ESLint config file somewhat bigger than the old JSHint config file, but given how rarely that one has been updated over the years I don't think that matters too much. I've tried, to the best of my ability, to ensure that we enable the same rules for ESLint that we had for JSHint. Furthermore, I've also enabled a number of rules that seemed to make sense, both to catch possible errors and various style guide violations. Despite the ESLint README claiming that it's slower that JSHint, https://github.com/eslint/eslint#how-does-eslint-performance-compare-to-jshint, locally this patch actually reduces the runtime for `gulp` lint (by approximately 20-25%). A couple of stylistic rules that would have been nice to enable, but where our code currently differs to much to make it feasible: - `comma-dangle`, controls trailing commas in Objects and Arrays (among others). - `object-curly-spacing`, controls spacing inside of Objects. - `spaced-comment`, used to enforce spaces after `//` and `/*. (This is made difficult by the fact that there's still some usage of the old preprocessor left.) Rules that I indend to look into possibly enabling in follow-ups, if it seems to make sense: `no-else-return`, `no-lonely-if`, `brace-style` with the `allowSingleLine` parameter removed. Useful links: - http://eslint.org/docs/user-guide/configuring - http://eslint.org/docs/rules/	8 years ago
Rob Wu	60438399e0	Fix typo in telemetry.js, follow-up to #7370	9 years ago
Rob Wu	724308c57a	Add opt-out telemetry to the Chrome extension Privacy policy: https://github.com/Rob--W/pdfjs-telemetry#privacy-policy Unit tests (offline): ``` node test/chromium/test-telemetry.js ``` Server tests (requires that Nginx is installed): ``` git clone https://github.com/Rob--W/pdfjs-telemetry.git cd pdfjs-telemetry/ python testserver.py TestHttp TestHttps ``` Integration test (extension + server): - Build the extension - Edit build/chromium/telemetry.js and remove the check for chrome.runtime.id. - Start Chrome (preferably a new profile): chromium --user-data-dir=/tmp/pdftest --no-first-run - Open chrome://net-internals#events - Visit chrome://extensions and enable Developer mode. - Load unpacked extension, select build/chromium. - Go to the chrome://net-internals tab and filter on pdfjs.robwu.nl. - Click on URL_REQUEST and verify that the server replied with 204. - Reload the extension. - Verify that chrome://net-internals did not contain a new log request.	9 years ago

Author

SHA1

Message

Date

Jonas Jenwald

2f3805efbc

Switch to using ESLint, instead of JSHint, for linting

*Please note that most of the necessary code adjustments were made in PR 7890.*

ESLint has a number of advantageous properties, compared to JSHint. Among those are:
- The ability to find subtle bugs, thanks to more rules (e.g. PR 7881).
- Much more customizable in general, and many rules allow fine-tuned behaviour rather than the just the on/off rules in JSHint.
- Many more rules that can help developers avoid bugs, and a lot of rules that can be used to enforce a consistent coding style. The latter should be particularily useful for new contributors (and reduce the amount of stylistic review comments necessary).
- The ability to easily specify exactly what rules to use/not to use, as opposed to JSHint which has a default set. *Note:* in future JSHint version some of the rules we depend on will be removed, according to warnings in http://jshint.com/docs/options/, so we wouldn't be able to update without losing lint coverage.
- More easily disable one, or more, rules temporarily. In JSHint this requires using a numeric code, which isn't very user friendly, whereas in ESLint the rule name is simply used instead.

By default there's no rules enabled in ESLint, but there are some default rule sets available. However, to prevent linting failures if we update ESLint in the future, it seemed easier to just explicitly specify what rules we want.
Obviously this makes the ESLint config file somewhat bigger than the old JSHint config file, but given how rarely that one has been updated over the years I don't think that matters too much.

I've tried, to the best of my ability, to ensure that we enable the same rules for ESLint that we had for JSHint. Furthermore, I've also enabled a number of rules that seemed to make sense, both to catch possible errors *and* various style guide violations.

Despite the ESLint README claiming that it's slower that JSHint, https://github.com/eslint/eslint#how-does-eslint-performance-compare-to-jshint, locally this patch actually reduces the runtime for `gulp` lint (by approximately 20-25%).

A couple of stylistic rules that would have been nice to enable, but where our code currently differs to much to make it feasible:
- `comma-dangle`, controls trailing commas in Objects and Arrays (among others).
- `object-curly-spacing`, controls spacing inside of Objects.
- `spaced-comment`, used to enforce spaces after `//` and `/*. (This is made difficult by the fact that there's still some usage of the old preprocessor left.)

Rules that I indend to look into possibly enabling in follow-ups, if it seems to make sense: `no-else-return`, `no-lonely-if`, `brace-style` with the `allowSingleLine` parameter removed.

Useful links:
- http://eslint.org/docs/user-guide/configuring
- http://eslint.org/docs/rules/

8 years ago

Rob Wu

60438399e0

Fix typo in telemetry.js, follow-up to #7370

9 years ago

Rob Wu

724308c57a

Add opt-out telemetry to the Chrome extension

Privacy policy: https://github.com/Rob--W/pdfjs-telemetry#privacy-policy

Unit tests (offline):

```
node test/chromium/test-telemetry.js
```

Server tests (requires that Nginx is installed):

```
git clone https://github.com/Rob--W/pdfjs-telemetry.git
cd pdfjs-telemetry/
python testserver.py TestHttp TestHttps
```

Integration test (extension + server):

- Build the extension
- Edit build/chromium/telemetry.js and remove the check for
  chrome.runtime.id.
- Start Chrome (preferably a new profile):
  chromium --user-data-dir=/tmp/pdftest --no-first-run
- Open chrome://net-internals#events
- Visit chrome://extensions and enable Developer mode.
- Load unpacked extension, select build/chromium.
- Go to the chrome://net-internals tab and filter on pdfjs.robwu.nl.
- Click on URL_REQUEST and verify that the server replied with 204.
- Reload the extension.
- Verify that chrome://net-internals did not contain a new log request.

9 years ago

3 Commits (a7c19d9cbb3e682821ce7430c62089a7cc90e6f0)