pdf.js/external/dist/lib/README.md

It's *very highly* recommended to *not* use these files, but rather use the
pre-built library as found in e.g. the `/build`, `/web`, and `/image_decoders`
folders in the root of this repository.

Please note that the "lib" build target exists mostly to enable unit-testing in
Node.js/Travis, and that you'll need to handle e.g. any necessary polyfills
and/or Node.js dependencies yourself if using the files in this folder.
Add a README file to the `/lib` folder in `pdfjs-dist` (issue 11539) 2020-01-28 11:26:40 +01:00			`It's very highly recommended to not use these files, but rather use the`
			pre-built library as found in e.g. the `/build`, `/web`, and `/image_decoders`
			`folders in the root of this repository.`

			`Please note that the "lib" build target exists mostly to enable unit-testing in`
Fail early, in modern `GENERIC` builds, if certain required browser functionality is missing (issue 11762) With two kind of builds now being produced, with/without translation/polyfills, it's unfortunately somewhat easy for users to accidentally pick the wrong one. In the case where a user would attempt to use a modern build of PDF.js in an older browser, such as e.g. IE11, the failure would be immediate when the code is loaded (given the use of unsupported ECMAScript features). However in some browsers/environments, in particular Node.js, a modern PDF.js build may load correctly and thus appear to function, only to fail for e.g. certain API calls. To hopefully lessen the support burden, and to try and improve things overall, this patch adds checks to ensure that a modern build of PDF.js cannot be used in browsers/environments which lack native support for critical functionality (such as e.g. `ReadableStream`). Hence we'll fail early, with an error message telling users to pick an ES5-compatible build instead. To ensure that we actually test things better especially w.r.t. usage of the PDF.js library in Node.js environments, the `gulp npm-test` task as used by Node.js/Travis was changed (back) to test an ES5-compatible build. (Since the bots still test the code as-is, without transpilation/polyfills, this shouldn't really be a problem as far as I can tell.) As part of these changes there's now both `gulp lib` and `gulp lib-es5` build targets, similar to e.g. the generic builds, which thanks to some re-factoring only required adding a small amount of code. Please note: While it's probably too early to tell if this will be a widespread issue, it's possible that this is the sort of patch that may warrant being `git cherry-pick`ed onto the current beta version (v2.4.456). 2020-04-01 13:31:33 +02:00			`Node.js/Travis, and that you'll need to handle e.g. any necessary polyfills`
			`and/or Node.js dependencies yourself if using the files in this folder.`