pdfjs-dist

Tree: c6e8ca863e

Author	SHA1	Message	Date
Jonas Jenwald	f41d80bdd3	Enable the `prefer-promise-reject-errors` ESLint rule See http://eslint.org/docs/rules/prefer-promise-reject-errors, note that this is similar to the already used `no-throw-literal` rule.	8 years ago
Jonas Jenwald	892fd84eb8	Add a couple of basic ES6 rules to the ESLint config See http://eslint.org/docs/rules/#ecmascript-6. To try and enforce consistent rules and to help avoid some possible errors in ES6 code from the start, this patch adds a few basic ESLint rules. Note that a two of the rules, `no-shadow` and `object-shorthand`, are currently disabled. While it'd certainly be nice to enable both of them, it's currently impossible since that would result in close to one thousand lint errors.	8 years ago
Yury Delendik	25873e92f0	Enable babel translation to enable ES module support.	8 years ago
Jonas Jenwald	a7c19d9cbb	Adjust the `yoda` ESLint rule to apply to inequalities as well I happened to notice that some inequalities had the wrong order, and was surprised since I thought that the `yoda` rule should have caught that. However, reading http://eslint.org/docs/rules/yoda#options a bit more closely than previously, it's quite obvious that the `onlyEquality` option does exactly what its name suggests. Hence I think that it makes sense to adjust the options such that only ranges are allowed instead.	8 years ago
Jonas Jenwald	d37d271afa	[api-minor] Reject the `RenderTask` with an actual `Error`, instead of just a `string`, when rendering is cancelled This patch gets rid of the only case in the code-base where we're throwing a plain `string`, rather than an `Error`, which besides better/more consistent error handling also allows us to enable the [`no-throw-literal`](http://eslint.org/docs/rules/no-throw-literal) ESLint rule.	8 years ago
Yury Delendik	5b50e0d414	Replaces RequireJS to SystemJS.	8 years ago
Jonas Jenwald	bc736fdc7d	Adjust the `brace-style` ESLint rule to disallow single lines (and also enable `no-iterator`) See http://eslint.org/docs/rules/brace-style. Having the opening/closing braces on the same line can often make the code slightly more difficult to read, in particular for `if`/`else if` statements, compared to using new lines. This patch also, for consistency with `mozilla-central`, enables the [`no-iterator`](http://eslint.org/docs/rules/no-iterator) rule. Note that this rule didn't require a single code change.	8 years ago
Jonas Jenwald	52e0f51917	Enable the `no-unused-vars` ESLint rule Please see http://eslint.org/docs/rules/no-unused-vars; note that this patch purposely uses the same rule options as in `mozilla-central`, such that it fixes part of issue 7957. It wasn't, in my opinion, entirely straightforward to enable this rule compared to the already existing rules. In many cases a `var descriptiveName = ...` format was used (more or less) to document the code, and I choose to place the old variable name in a trailing comment to not lose that information. I welcome feedback on these changes, since it wasn't always entirely easy to know what changes made the most sense in every situation.	8 years ago
Jonas Jenwald	f77c52291e	Enable the `no-empty-pattern`/`no-floating-decimal`/`no-self-compare`/`no-delete-var`/`no-new-object` ESLint rules The following rules required no code changes: http://eslint.org/docs/rules/no-empty-pattern http://eslint.org/docs/rules/no-floating-decimal http://eslint.org/docs/rules/no-delete-var http://eslint.org/docs/rules/no-new-object There was just one change needed in order to enable: http://eslint.org/docs/rules/no-self-compare; which I think helps readability a lot, since that comparison makes no sense until you realize that we push `NaN` onto the `stack` in some cases and furthermore that `NaN !== NaN`.	8 years ago
Jonas Jenwald	3ec99f0e12	[Firefox addon] Convert the code to be ES6 friendly, in order to better agree with mozilla-central coding conventions (issue 7957) Please note: ignoring whitespace changes is most likely necessary for the diff to be readable. This patch addresses all the current, in `mozilla-central`, linting failures in the addon. It should thus be possible to change the `.eslintignore` entry for PDF.js in `mozilla-central` from `browser/extensions/pdfjs/` to `browser/extensions/pdfjs/build/` and `browser/extensions/pdfjs/web/**` instead. Note that we cannot, for backwards compatibility reason of the general PDF.js library, at this time make similar changes for files residing in the `build` and `web` directories in `mozilla-central`. The main changes in this patch are that we now use [classes](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes) instead of our previous "class-like" functions, and also use the more compact [object shorthand notation](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Operators/Object_initializer#New_notations_in_ECMAScript_2015). A couple of functions were also converted to [arrow functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions), to reduced usages of `bind(this)` and `var self = this`. One caveat with ES6 classes is that it's not (yet) possible to define private constants/helper functions within them, which is why the `NetworkManagerClosure` was kept to not change the visibility of those constant/functions. Besides testing in Firefox Nightly 53, this patch has also been tested in Firefox ESR 45 and SeaMonkey 2.46. However, I'd gladly welcome help with testing the patch more, to ensure that nothing has gone wrong during the refactoring. Fixes the first bullet point of issue 7957.	8 years ago
Jonas Jenwald	82ea7e6e6e	Enable the `no-unsafe-finally`/`no-octal`/`no-useless-call` ESLint rules http://eslint.org/docs/rules/no-unsafe-finally, there's just one violation which in this case can actually be ignored since there's nothing `return`ed there. http://eslint.org/docs/rules/no-octal, there're no violations in the code-base. http://eslint.org/docs/rules/no-useless-call, there's just one violation that needs to be fixed.	8 years ago
Jonas Jenwald	31684e6918	Enable the `no-lone-blocks` ESLint rule http://eslint.org/docs/rules/no-lone-blocks Note that we currently have no code that violates this rule in the source files, but it seems that the built files are possibly affected (see issue 7957).	8 years ago
Jonas Jenwald	4626fc8342	Enable the `spaced-comment` ESLint rule Please see http://eslint.org/docs/rules/spaced-comment. Note that the exceptions added for `line` comments are intended to still allow use of the old preprocessor without linting errors. Also, I took the opportunity to improve the grammar slightly (w.r.t. capitalization and punctuation) for comments touched in the patch.	8 years ago
Jonas Jenwald	0dff8f3600	Adjust the `space-unary-ops` ESLint rule to comply with mozilla-central lint rules See http://eslint.org/docs/rules/space-unary-ops; a very small part of issue 7957.	8 years ago
Jonas Jenwald	4046d67fde	Enable the `no-else-return` ESLint rule Using `else` after `return` is not necessary, and can often lead to unnecessarily cluttered code. By using the `no-else-return` rule in ESLint we can avoid this pattern, see http://eslint.org/docs/rules/no-else-return.	8 years ago
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

18 Commits (c6e8ca863e95e409d2d58037467981fe63ba9555)