akira/pdfjs-dist - pdfjs-dist - Gitea: Git with a cup of tea

Tree: c67edabcb3

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
Manas	a2ba1b8189	Uses editorconfig to maintain consistent coding styles Removes the following as they unnecessary /* -- Mode: Java; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -- / / vim: set shiftwidth=2 tabstop=2 autoindent cindent expandtab: */	10 years ago
Rob Wu	cc0805a996	Reduce verbosity of output in test/webbrowser.js	10 years ago
Rob Wu	c3c6d503ee	Improve robustness of builder (esp. on Windows) - Use rimraf instead of a custom removeDirSync implementation - rimraf deals with edge cases like EPERM on Windows. - Detect when the process exits before it was requested via stop(), instead of running the cleanup handler. - Add fallback for process detection when the process exits before it was requested. On *nix systems, this is done via pkill and pgrep, on Windows this is done via wmic. - Add some asserts to check the preconditions of the methods, and output some status information to aid debugging in case of failure. I have verified that these changes work on ArchLinux and Windows XP, using Chrome and Firefox, as follows: 1. node make unittest 2. node make unittest 3. Restart the Firefox process via the task manager as soon as possible. 4. node make unittest 5. Temporary lock a file/directory within the temporary profile directory until the tests have finished, and then unlock the file within 10 seconds. In all cases, the auxilary browser processes are killed, and the temporary profile directory is wiped.	10 years ago
Rob Wu	62cf6536a2	Tests: Resolve -b to full path in webbrowser.js This allows us to simply use "node test.js -b=firefox" instead of having to type out the full path.	10 years ago
Rob Wu	5cce7377af	Use taskkill to stop the browser on Windows	10 years ago
Marco Castelluccio	fbae39983c	Fail with a more informative error message if the browser executable path doesn't exist	10 years ago
Yury Delendik	98ab547140	Fixes webbrowser.js to avoid undefined callback call	11 years ago
Yury Delendik	89a676a49c	Protects from killing a closed process	11 years ago
Yury Delendik	b72094d740	Using shell/cmd commands to kill browser tasks	11 years ago
Thorben Bochenek	c834ba7c3e	Make Opera a possible browser to test with	11 years ago
Yury Delendik	d7174582c0	Better test process killing for Windows	11 years ago
Yury Delendik	c2376e5cea	Migrating test.py to test.js	11 years ago