2016-03-05 00:36:46 +09:00
|
|
|
/* Copyright 2016 Mozilla Foundation
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
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/
2016-12-15 23:52:29 +09:00
|
|
|
/* eslint-env node */
|
2016-03-05 00:36:46 +09:00
|
|
|
|
2023-07-08 22:33:03 +09:00
|
|
|
import { exec, spawn, spawnSync } from "child_process";
|
|
|
|
import autoprefixer from "autoprefixer";
|
2023-07-13 19:20:58 +09:00
|
|
|
import babel from "@babel/core";
|
2023-07-08 22:33:03 +09:00
|
|
|
import crypto from "crypto";
|
|
|
|
import { fileURLToPath } from "url";
|
|
|
|
import fs from "fs";
|
|
|
|
import gulp from "gulp";
|
|
|
|
import merge from "merge-stream";
|
|
|
|
import { mkdirp } from "mkdirp";
|
|
|
|
import path from "path";
|
|
|
|
import postcss from "gulp-postcss";
|
|
|
|
import postcssDirPseudoClass from "postcss-dir-pseudo-class";
|
2023-09-23 01:27:08 +09:00
|
|
|
import postcssDiscardComments from "postcss-discard-comments";
|
2023-08-05 01:21:27 +09:00
|
|
|
import postcssNesting from "postcss-nesting";
|
2023-10-18 20:32:50 +09:00
|
|
|
import { preprocess } from "./external/builder/builder.mjs";
|
2023-07-08 23:07:54 +09:00
|
|
|
import { preprocessPDFJSCode } from "./external/builder/preprocessor2.mjs";
|
2023-07-08 22:33:03 +09:00
|
|
|
import rename from "gulp-rename";
|
|
|
|
import replace from "gulp-replace";
|
|
|
|
import rimraf from "rimraf";
|
|
|
|
import stream from "stream";
|
|
|
|
import streamqueue from "streamqueue";
|
|
|
|
import through from "through2";
|
|
|
|
import Vinyl from "vinyl";
|
|
|
|
import webpack2 from "webpack";
|
|
|
|
import webpackStream from "webpack-stream";
|
|
|
|
import zip from "gulp-zip";
|
|
|
|
|
|
|
|
const __dirname = path.dirname(fileURLToPath(import.meta.url));
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
|
|
|
|
const BUILD_DIR = "build/";
|
|
|
|
const L10N_DIR = "l10n/";
|
|
|
|
const TEST_DIR = "test/";
|
|
|
|
const EXTENSION_SRC_DIR = "extensions/";
|
|
|
|
|
|
|
|
const BASELINE_DIR = BUILD_DIR + "baseline/";
|
|
|
|
const MOZCENTRAL_BASELINE_DIR = BUILD_DIR + "mozcentral.baseline/";
|
|
|
|
const GENERIC_DIR = BUILD_DIR + "generic/";
|
|
|
|
const GENERIC_LEGACY_DIR = BUILD_DIR + "generic-legacy/";
|
|
|
|
const COMPONENTS_DIR = BUILD_DIR + "components/";
|
|
|
|
const COMPONENTS_LEGACY_DIR = BUILD_DIR + "components-legacy/";
|
|
|
|
const IMAGE_DECODERS_DIR = BUILD_DIR + "image_decoders/";
|
|
|
|
const IMAGE_DECODERS_LEGACY_DIR = BUILD_DIR + "image_decoders-legacy/";
|
|
|
|
const DEFAULT_PREFERENCES_DIR = BUILD_DIR + "default_preferences/";
|
|
|
|
const MINIFIED_DIR = BUILD_DIR + "minified/";
|
|
|
|
const MINIFIED_LEGACY_DIR = BUILD_DIR + "minified-legacy/";
|
|
|
|
const JSDOC_BUILD_DIR = BUILD_DIR + "jsdoc/";
|
|
|
|
const GH_PAGES_DIR = BUILD_DIR + "gh-pages/";
|
|
|
|
const SRC_DIR = "src/";
|
|
|
|
const DIST_DIR = BUILD_DIR + "dist/";
|
|
|
|
const TYPES_DIR = BUILD_DIR + "types/";
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
const TMP_DIR = BUILD_DIR + "tmp/";
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const TYPESTEST_DIR = BUILD_DIR + "typestest/";
|
Move the `PDFBug`-related CSS from `viewer.css` and into its own file
Given that none of these CSS rules are used at all, unless debugging is enabled, it seems completely unnecessary to load them *unconditionally* for all users.[1]
Note that if *both* the `textLayer` and `pdfBug` debugging hash-parameters are specified simultaneously, we'll now load the `PDFBug`-file *twice* (since the code is simpler that way). However, given first of all that none of this is enabled by default and secondly that using those parameters together isn't helpful[2], potentially loading that file twice is hopefully not an issue.
For the `gulp mozcentral` target, the size of the *built* `viewer.css` file is reduced `> 3%` with this patch.
---
[1] For the Firefox built-in PDF Viewer, in order to even be able to access the `PDFBug` functionality, you need to first of all set `pdfjs.pdfBugEnabled = true` manually in `about:config`. Secondly, you then also need to append the `pdfBug=...` hash-parameter to the URL when *initially* loading the document.
[2] Note how the `textLayer`-settings are already, since essentially forever, overriding the highlighting-features of the "FontInspector"-tab.
2022-04-06 01:14:17 +09:00
|
|
|
const COMMON_WEB_FILES = [
|
|
|
|
"web/images/*.{png,svg,gif}",
|
2023-10-08 20:14:09 +09:00
|
|
|
"web/debugger.{css,mjs}",
|
Move the `PDFBug`-related CSS from `viewer.css` and into its own file
Given that none of these CSS rules are used at all, unless debugging is enabled, it seems completely unnecessary to load them *unconditionally* for all users.[1]
Note that if *both* the `textLayer` and `pdfBug` debugging hash-parameters are specified simultaneously, we'll now load the `PDFBug`-file *twice* (since the code is simpler that way). However, given first of all that none of this is enabled by default and secondly that using those parameters together isn't helpful[2], potentially loading that file twice is hopefully not an issue.
For the `gulp mozcentral` target, the size of the *built* `viewer.css` file is reduced `> 3%` with this patch.
---
[1] For the Firefox built-in PDF Viewer, in order to even be able to access the `PDFBug` functionality, you need to first of all set `pdfjs.pdfBugEnabled = true` manually in `about:config`. Secondly, you then also need to append the `pdfBug=...` hash-parameter to the URL when *initially* loading the document.
[2] Note how the `textLayer`-settings are already, since essentially forever, overriding the highlighting-features of the "FontInspector"-tab.
2022-04-06 01:14:17 +09:00
|
|
|
];
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const MOZCENTRAL_DIFF_FILE = "mozcentral.diff";
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const DIST_REPO_URL = "https://github.com/mozilla/pdfjs-dist";
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const CONFIG_FILE = "pdfjs.config";
|
|
|
|
const config = JSON.parse(fs.readFileSync(CONFIG_FILE).toString());
|
2016-04-23 07:20:47 +09:00
|
|
|
|
2022-08-19 17:45:40 +09:00
|
|
|
const ENV_TARGETS = [
|
|
|
|
"last 2 versions",
|
2023-05-31 17:47:57 +09:00
|
|
|
"Chrome >= 92",
|
2022-08-19 17:45:40 +09:00
|
|
|
"Firefox ESR",
|
[api-minor] Update the minimum supported Safari version to 15.4
This patch updates the minimum supported browsers as follows:
- Safari 15.4, which was released on 2022-03-15; see https://en.wikipedia.org/wiki/Safari_version_history#Safari_15
Nowadays we usually we try, where feasible and possible, to support browsers that are about two years old. The reasons for limiting support to a *somewhat* more recent Safari version include:
- Throughout the history of the PDF.js project, Safari has always been the worst browser to attempt to support. Compared to other browsers there's a disproportionate number of bugs affecting Safari, especially on iOS, and in most cases those are browser-specific issues that we simply cannot address.[1]
- Safari has often been a lot slower, compared to other browsers, at implementing new web-platform features. Historically this has sometimes blocked usage of new features, for the benefit of the Firefox PDF Viewer, and it's very often meant having to include and maintain polyfills *only* for Safari.
- The current (minimum) supported Safari version lack enough functionality that polyfills placed in the `src/shared/compatibility.js` file are unfortunately not sufficient, but it also requires a bunch of special-cases in both the `gulpfile` and in the `web/`-code.
- Given that the *built-in* Firefox PDF Viewer is the primary development target for the PDF.js library, and the general development pace these days, we need to limit the maintenance "overhead" caused by other browsers.
---
[1] In a few cases a work-around might be possible, however it'd negatively affect e.g. performance, readability, and/or maintainability of the code.
2023-04-29 15:58:44 +09:00
|
|
|
"Safari >= 15.4",
|
2023-04-05 17:40:19 +09:00
|
|
|
"Node >= 18",
|
2022-08-19 17:45:40 +09:00
|
|
|
"> 1%",
|
|
|
|
"not IE > 0",
|
|
|
|
"not dead",
|
|
|
|
];
|
|
|
|
|
Add a `gulp image_decoders` command to allow packaging/distributing the image decoders (i.e. jpg.js, jpx.js, jbig2.js) separately from the main PDF.js library
Please note that the standalone `pdf.image_decoders.js` file will be including the complete `src/shared/util.js` file, despite only using parts of it.[1] This was done *purposely*, to not negatively impact the readability/maintainability of the core PDF.js code.
Furthermore, to ensure that the compatibility is the same in the regular PDF.js library *and* in the the standalone image decoders, `src/shared/compatibility.js` was included as well.
To (hopefully) prevent future complaints about the size of the built `pdf.image_decoders.js` file, a few existing async-related polyfills are being skipped (since all of the image decoders are completely synchronous).
Obviously this required adding a couple of pre-processor statements, but given that these are all limited to "compatibility" code, I think this might be OK!?
---
[1] However, please note that previous commits moved `PageViewport` and `MessageHandler` out of `src/shared/util.js` which reduced its size.
2018-05-16 20:49:26 +09:00
|
|
|
// Default Autoprefixer config used for generic, components, minified-pre
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const AUTOPREFIXER_CONFIG = {
|
2022-08-19 17:45:40 +09:00
|
|
|
overrideBrowserslist: ENV_TARGETS,
|
2018-04-04 21:51:29 +09:00
|
|
|
};
|
2022-08-19 17:45:40 +09:00
|
|
|
// Default Babel targets used for generic, components, minified-pre
|
|
|
|
const BABEL_TARGETS = ENV_TARGETS.join(", ");
|
2018-04-04 21:51:29 +09:00
|
|
|
|
2020-05-10 20:38:58 +09:00
|
|
|
const DEFINES = Object.freeze({
|
2019-10-15 04:19:31 +09:00
|
|
|
SKIP_BABEL: true,
|
2021-08-20 02:54:36 +09:00
|
|
|
TESTING: undefined,
|
2016-04-23 07:20:47 +09:00
|
|
|
// The main build targets:
|
|
|
|
GENERIC: false,
|
|
|
|
MOZCENTRAL: false,
|
2022-12-15 00:40:25 +09:00
|
|
|
GECKOVIEW: false,
|
2016-04-23 07:20:47 +09:00
|
|
|
CHROME: false,
|
|
|
|
MINIFIED: false,
|
2017-03-14 01:35:33 +09:00
|
|
|
COMPONENTS: false,
|
2017-04-25 05:07:00 +09:00
|
|
|
LIB: false,
|
Add a `gulp image_decoders` command to allow packaging/distributing the image decoders (i.e. jpg.js, jpx.js, jbig2.js) separately from the main PDF.js library
Please note that the standalone `pdf.image_decoders.js` file will be including the complete `src/shared/util.js` file, despite only using parts of it.[1] This was done *purposely*, to not negatively impact the readability/maintainability of the core PDF.js code.
Furthermore, to ensure that the compatibility is the same in the regular PDF.js library *and* in the the standalone image decoders, `src/shared/compatibility.js` was included as well.
To (hopefully) prevent future complaints about the size of the built `pdf.image_decoders.js` file, a few existing async-related polyfills are being skipped (since all of the image decoders are completely synchronous).
Obviously this required adding a couple of pre-processor statements, but given that these are all limited to "compatibility" code, I think this might be OK!?
---
[1] However, please note that previous commits moved `PageViewport` and `MessageHandler` out of `src/shared/util.js` which reduced its size.
2018-05-16 20:49:26 +09:00
|
|
|
IMAGE_DECODERS: false,
|
2020-05-10 20:38:58 +09:00
|
|
|
});
|
2016-03-05 00:36:46 +09:00
|
|
|
|
2019-11-13 11:51:31 +09:00
|
|
|
function transform(charEncoding, transformFunction) {
|
2020-04-14 19:28:14 +09:00
|
|
|
return through.obj(function (vinylFile, enc, done) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const transformedFile = vinylFile.clone();
|
2019-11-13 11:51:31 +09:00
|
|
|
transformedFile.contents = Buffer.from(
|
|
|
|
transformFunction(transformedFile.contents),
|
|
|
|
charEncoding
|
|
|
|
);
|
|
|
|
done(null, transformedFile);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2017-04-28 06:21:26 +09:00
|
|
|
function safeSpawnSync(command, parameters, options) {
|
|
|
|
// Execute all commands in a shell.
|
|
|
|
options = options || {};
|
|
|
|
options.shell = true;
|
2017-05-03 22:17:31 +09:00
|
|
|
// `options.shell = true` requires parameters to be quoted.
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
parameters = parameters.map(param => {
|
2020-11-07 20:59:53 +09:00
|
|
|
if (!/[\s`~!#$*(){[|\\;'"<>?]/.test(param)) {
|
2017-05-03 22:17:31 +09:00
|
|
|
return param;
|
|
|
|
}
|
2023-03-23 20:34:08 +09:00
|
|
|
return '"' + param.replaceAll(/([$\\"`])/g, "\\$1") + '"';
|
2017-05-03 22:17:31 +09:00
|
|
|
});
|
2017-04-28 06:21:26 +09:00
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const result = spawnSync(command, parameters, options);
|
2017-04-28 06:21:26 +09:00
|
|
|
if (result.status !== 0) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log(
|
|
|
|
'Error: command "' +
|
|
|
|
command +
|
|
|
|
'" with parameters "' +
|
|
|
|
parameters +
|
|
|
|
'" exited with code ' +
|
|
|
|
result.status
|
|
|
|
);
|
2017-04-28 06:21:26 +09:00
|
|
|
process.exit(result.status);
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2019-06-29 20:23:43 +09:00
|
|
|
function startNode(args, options) {
|
|
|
|
// Node.js decreased the maximum header size from 80 KB to 8 KB in newer
|
|
|
|
// releases, which is not sufficient for some of our reference test files
|
|
|
|
// (such as `issue6360.pdf`), so we need to restore this value. Note that
|
|
|
|
// this argument needs to be before all other arguments as it needs to be
|
|
|
|
// passed to the Node.js process itself and not to the script that it runs.
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
args.unshift("--max-http-header-size=80000");
|
|
|
|
return spawn("node", args, options);
|
2019-06-29 20:23:43 +09:00
|
|
|
}
|
|
|
|
|
2016-03-05 00:36:46 +09:00
|
|
|
function createStringSource(filename, content) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const source = stream.Readable({ objectMode: true });
|
2020-04-14 19:28:14 +09:00
|
|
|
source._read = function () {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.push(
|
|
|
|
new Vinyl({
|
|
|
|
path: filename,
|
|
|
|
contents: Buffer.from(content),
|
|
|
|
})
|
|
|
|
);
|
2016-03-05 00:36:46 +09:00
|
|
|
this.push(null);
|
|
|
|
};
|
|
|
|
return source;
|
|
|
|
}
|
|
|
|
|
2020-12-04 23:49:13 +09:00
|
|
|
function createWebpackConfig(
|
|
|
|
defines,
|
|
|
|
output,
|
2020-12-05 23:51:39 +09:00
|
|
|
{
|
|
|
|
disableVersionInfo = false,
|
|
|
|
disableSourceMaps = false,
|
|
|
|
disableLicenseHeader = false,
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
defaultPreferencesDir = null,
|
2020-12-05 23:51:39 +09:00
|
|
|
} = {}
|
2020-12-04 23:49:13 +09:00
|
|
|
) {
|
2020-12-05 23:51:39 +09:00
|
|
|
const versionInfo = !disableVersionInfo
|
|
|
|
? getVersionJSON()
|
|
|
|
: { version: 0, commit: 0 };
|
2023-10-18 20:32:50 +09:00
|
|
|
const bundleDefines = {
|
|
|
|
...defines,
|
2017-02-09 07:32:15 +09:00
|
|
|
BUNDLE_VERSION: versionInfo.version,
|
Fix the remaining cases of inconsistent spacing and trailing commas in objects, and enable the `comma-dangle` and `object-curly-spacing` ESLint rules
http://eslint.org/docs/rules/comma-dangle
http://eslint.org/docs/rules/object-curly-spacing
*Please note:* This patch was created automatically, using the ESLint `--fix` command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch.
```diff
diff --git a/gulpfile.js b/gulpfile.js
index d18b9c58..7d47fd8d 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -1247,7 +1247,8 @@ gulp.task('gh-pages-git', ['gh-pages-prepare', 'wintersmith'], function () {
var reason = process.env['PDFJS_UPDATE_REASON'];
safeSpawnSync('git', ['init'], { cwd: GH_PAGES_DIR, });
- safeSpawnSync('git', ['remote', 'add', 'origin', REPO], { cwd: GH_PAGES_DIR, });
+ safeSpawnSync('git', ['remote', 'add', 'origin', REPO],
+ { cwd: GH_PAGES_DIR, });
safeSpawnSync('git', ['add', '-A'], { cwd: GH_PAGES_DIR, });
safeSpawnSync('git', [
'commit', '-am', 'gh-pages site created via gulpfile.js script',
```
2017-06-03 00:13:35 +09:00
|
|
|
BUNDLE_BUILD: versionInfo.commit,
|
2023-06-25 23:02:31 +09:00
|
|
|
TESTING: defines.TESTING ?? process.env.TESTING === "true",
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
DEFAULT_PREFERENCES: defaultPreferencesDir
|
|
|
|
? getDefaultPreferences(defaultPreferencesDir)
|
|
|
|
: {},
|
2023-10-18 20:32:50 +09:00
|
|
|
};
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const licenseHeaderLibre = fs
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
.readFileSync("./src/license_header_libre.js")
|
|
|
|
.toString();
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const enableSourceMaps =
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
!bundleDefines.MOZCENTRAL &&
|
|
|
|
!bundleDefines.CHROME &&
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
!bundleDefines.LIB &&
|
2020-11-09 22:45:02 +09:00
|
|
|
!bundleDefines.TESTING &&
|
2020-12-04 23:49:13 +09:00
|
|
|
!disableSourceMaps;
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
const isModule = output.library?.type === "module";
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const skipBabel = bundleDefines.SKIP_BABEL;
|
2017-02-09 07:32:15 +09:00
|
|
|
|
2023-08-12 17:09:03 +09:00
|
|
|
// `core-js`, see https://github.com/zloirock/core-js/issues/514,
|
|
|
|
// should be excluded from processing.
|
2022-04-17 17:16:50 +09:00
|
|
|
const babelExcludes = ["node_modules[\\\\\\/]core-js"];
|
2020-10-25 21:37:22 +09:00
|
|
|
const babelExcludeRegExp = new RegExp(`(${babelExcludes.join("|")})`);
|
|
|
|
|
2023-07-17 22:44:30 +09:00
|
|
|
const babelPresets = skipBabel
|
|
|
|
? undefined
|
|
|
|
: [
|
|
|
|
[
|
|
|
|
"@babel/preset-env",
|
2023-10-07 23:30:27 +09:00
|
|
|
{
|
2023-10-14 20:44:21 +09:00
|
|
|
corejs: "3.33.0",
|
2023-10-07 23:30:27 +09:00
|
|
|
exclude: ["web.structured-clone"],
|
|
|
|
shippedProposals: true,
|
|
|
|
useBuiltIns: "usage",
|
|
|
|
},
|
2023-07-17 22:44:30 +09:00
|
|
|
],
|
|
|
|
];
|
2023-10-13 19:11:29 +09:00
|
|
|
const babelPlugins = [];
|
2021-01-22 22:06:21 +09:00
|
|
|
|
2020-12-04 23:49:13 +09:00
|
|
|
const plugins = [];
|
|
|
|
if (!disableLicenseHeader) {
|
|
|
|
plugins.push(
|
|
|
|
new webpack2.BannerPlugin({ banner: licenseHeaderLibre, raw: true })
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
const experiments = isModule ? { outputModule: true } : undefined;
|
2022-07-07 06:02:53 +09:00
|
|
|
|
2018-05-20 22:18:43 +09:00
|
|
|
// Required to expose e.g., the `window` object.
|
2022-05-14 17:02:06 +09:00
|
|
|
output.globalObject = "globalThis";
|
2018-05-20 22:18:43 +09:00
|
|
|
|
2023-02-04 21:55:12 +09:00
|
|
|
const basicAlias = {
|
|
|
|
pdfjs: "src",
|
|
|
|
"pdfjs-web": "web",
|
|
|
|
"pdfjs-lib": "web/pdfjs",
|
2023-10-13 23:23:17 +09:00
|
|
|
"fluent-bundle": "node_modules/@fluent/bundle/esm/index.js",
|
|
|
|
"fluent-dom": "node_modules/@fluent/dom/esm/index.js",
|
2023-02-04 21:55:12 +09:00
|
|
|
};
|
2023-07-13 18:58:16 +09:00
|
|
|
const libraryAlias = {
|
|
|
|
"display-fetch_stream": "src/display/stubs.js",
|
|
|
|
"display-l10n_utils": "src/display/stubs.js",
|
|
|
|
"display-network": "src/display/stubs.js",
|
|
|
|
"display-node_stream": "src/display/stubs.js",
|
|
|
|
"display-node_utils": "src/display/stubs.js",
|
|
|
|
};
|
2023-02-04 21:55:12 +09:00
|
|
|
const viewerAlias = {
|
2023-09-21 19:51:34 +09:00
|
|
|
"web-alt_text_manager": "web/alt_text_manager.js",
|
2023-02-04 21:55:12 +09:00
|
|
|
"web-annotation_editor_params": "web/annotation_editor_params.js",
|
2023-02-06 00:13:18 +09:00
|
|
|
"web-com": "",
|
2023-10-19 03:13:10 +09:00
|
|
|
"web-l10n_utils": "web/stubs.js",
|
2023-02-04 21:55:12 +09:00
|
|
|
"web-pdf_attachment_viewer": "web/pdf_attachment_viewer.js",
|
|
|
|
"web-pdf_cursor_tools": "web/pdf_cursor_tools.js",
|
|
|
|
"web-pdf_document_properties": "web/pdf_document_properties.js",
|
|
|
|
"web-pdf_find_bar": "web/pdf_find_bar.js",
|
|
|
|
"web-pdf_layer_viewer": "web/pdf_layer_viewer.js",
|
|
|
|
"web-pdf_outline_viewer": "web/pdf_outline_viewer.js",
|
|
|
|
"web-pdf_presentation_mode": "web/pdf_presentation_mode.js",
|
|
|
|
"web-pdf_sidebar": "web/pdf_sidebar.js",
|
|
|
|
"web-pdf_thumbnail_viewer": "web/pdf_thumbnail_viewer.js",
|
2023-02-06 00:13:18 +09:00
|
|
|
"web-print_service": "",
|
2023-02-04 21:55:12 +09:00
|
|
|
"web-secondary_toolbar": "web/secondary_toolbar.js",
|
|
|
|
"web-toolbar": "web/toolbar.js",
|
|
|
|
};
|
2023-02-06 00:13:18 +09:00
|
|
|
if (bundleDefines.CHROME) {
|
2023-07-13 18:58:16 +09:00
|
|
|
libraryAlias["display-fetch_stream"] = "src/display/fetch_stream.js";
|
|
|
|
libraryAlias["display-network"] = "src/display/network.js";
|
|
|
|
|
2023-02-06 00:13:18 +09:00
|
|
|
viewerAlias["web-com"] = "web/chromecom.js";
|
|
|
|
viewerAlias["web-print_service"] = "web/pdf_print_service.js";
|
|
|
|
} else if (bundleDefines.GENERIC) {
|
2023-08-31 19:59:27 +09:00
|
|
|
// Aliases defined here must also be replicated in the paths section of
|
|
|
|
// the tsconfig.json file for the type generation to work.
|
|
|
|
// In the tsconfig.json files, the .js extension must be omitted.
|
2023-07-13 18:58:16 +09:00
|
|
|
libraryAlias["display-fetch_stream"] = "src/display/fetch_stream.js";
|
|
|
|
libraryAlias["display-l10n_utils"] = "web/l10n_utils.js";
|
|
|
|
libraryAlias["display-network"] = "src/display/network.js";
|
|
|
|
libraryAlias["display-node_stream"] = "src/display/node_stream.js";
|
|
|
|
libraryAlias["display-node_utils"] = "src/display/node_utils.js";
|
|
|
|
|
2023-02-06 00:13:18 +09:00
|
|
|
viewerAlias["web-com"] = "web/genericcom.js";
|
2023-10-19 03:13:10 +09:00
|
|
|
viewerAlias["web-l10n_utils"] = "web/l10n_utils.js";
|
2023-02-06 00:13:18 +09:00
|
|
|
viewerAlias["web-print_service"] = "web/pdf_print_service.js";
|
|
|
|
} else if (bundleDefines.MOZCENTRAL) {
|
|
|
|
if (bundleDefines.GECKOVIEW) {
|
2023-04-07 17:28:53 +09:00
|
|
|
const gvAlias = {
|
2023-10-19 03:13:10 +09:00
|
|
|
"web-l10n_utils": "web/stubs.js",
|
2023-04-07 17:28:53 +09:00
|
|
|
"web-toolbar": "web/toolbar-geckoview.js",
|
|
|
|
};
|
2023-02-06 00:13:18 +09:00
|
|
|
for (const key in viewerAlias) {
|
2023-04-07 17:28:53 +09:00
|
|
|
viewerAlias[key] = gvAlias[key] || "web/stubs-geckoview.js";
|
2023-02-06 00:13:18 +09:00
|
|
|
}
|
2023-02-04 21:55:12 +09:00
|
|
|
}
|
2023-02-06 00:13:18 +09:00
|
|
|
viewerAlias["web-com"] = "web/firefoxcom.js";
|
2023-03-16 22:22:14 +09:00
|
|
|
viewerAlias["web-print_service"] = "web/firefox_print_service.js";
|
2023-02-04 21:55:12 +09:00
|
|
|
}
|
2023-07-13 18:58:16 +09:00
|
|
|
const alias = { ...basicAlias, ...libraryAlias, ...viewerAlias };
|
2023-02-04 21:55:12 +09:00
|
|
|
for (const key in alias) {
|
|
|
|
alias[key] = path.join(__dirname, alias[key]);
|
|
|
|
}
|
|
|
|
|
2017-02-09 07:32:15 +09:00
|
|
|
return {
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
mode: "production",
|
|
|
|
optimization: {
|
|
|
|
mangleExports: false,
|
|
|
|
minimize: false,
|
|
|
|
},
|
2022-07-07 06:02:53 +09:00
|
|
|
experiments,
|
2021-01-23 01:38:26 +09:00
|
|
|
output,
|
2018-05-20 22:18:43 +09:00
|
|
|
performance: {
|
|
|
|
hints: false, // Disable messages about larger file sizes.
|
|
|
|
},
|
2020-12-04 23:49:13 +09:00
|
|
|
plugins,
|
2017-02-09 07:32:15 +09:00
|
|
|
resolve: {
|
2023-02-04 21:55:12 +09:00
|
|
|
alias,
|
2017-02-09 07:32:15 +09:00
|
|
|
},
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
devtool: enableSourceMaps ? "source-map" : undefined,
|
2017-02-09 07:32:15 +09:00
|
|
|
module: {
|
2018-05-20 22:18:43 +09:00
|
|
|
rules: [
|
2017-03-06 23:42:48 +09:00
|
|
|
{
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
loader: "babel-loader",
|
2020-10-25 21:37:22 +09:00
|
|
|
exclude: babelExcludeRegExp,
|
2017-03-06 23:42:48 +09:00
|
|
|
options: {
|
2023-07-17 22:44:30 +09:00
|
|
|
presets: babelPresets,
|
2021-01-22 22:06:21 +09:00
|
|
|
plugins: babelPlugins,
|
2022-08-19 17:45:40 +09:00
|
|
|
targets: BABEL_TARGETS,
|
Fix the remaining cases of inconsistent spacing and trailing commas in objects, and enable the `comma-dangle` and `object-curly-spacing` ESLint rules
http://eslint.org/docs/rules/comma-dangle
http://eslint.org/docs/rules/object-curly-spacing
*Please note:* This patch was created automatically, using the ESLint `--fix` command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch.
```diff
diff --git a/gulpfile.js b/gulpfile.js
index d18b9c58..7d47fd8d 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -1247,7 +1247,8 @@ gulp.task('gh-pages-git', ['gh-pages-prepare', 'wintersmith'], function () {
var reason = process.env['PDFJS_UPDATE_REASON'];
safeSpawnSync('git', ['init'], { cwd: GH_PAGES_DIR, });
- safeSpawnSync('git', ['remote', 'add', 'origin', REPO], { cwd: GH_PAGES_DIR, });
+ safeSpawnSync('git', ['remote', 'add', 'origin', REPO],
+ { cwd: GH_PAGES_DIR, });
safeSpawnSync('git', ['add', '-A'], { cwd: GH_PAGES_DIR, });
safeSpawnSync('git', [
'commit', '-am', 'gh-pages site created via gulpfile.js script',
```
2017-06-03 00:13:35 +09:00
|
|
|
},
|
2017-03-06 23:42:48 +09:00
|
|
|
},
|
2017-02-09 07:32:15 +09:00
|
|
|
{
|
2023-07-08 23:07:54 +09:00
|
|
|
loader: path.join(__dirname, "external/webpack/pdfjsdev-loader.mjs"),
|
2017-02-09 07:32:15 +09:00
|
|
|
options: {
|
|
|
|
rootPath: __dirname,
|
2017-02-09 07:35:58 +09:00
|
|
|
saveComments: false,
|
Fix the remaining cases of inconsistent spacing and trailing commas in objects, and enable the `comma-dangle` and `object-curly-spacing` ESLint rules
http://eslint.org/docs/rules/comma-dangle
http://eslint.org/docs/rules/object-curly-spacing
*Please note:* This patch was created automatically, using the ESLint `--fix` command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch.
```diff
diff --git a/gulpfile.js b/gulpfile.js
index d18b9c58..7d47fd8d 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -1247,7 +1247,8 @@ gulp.task('gh-pages-git', ['gh-pages-prepare', 'wintersmith'], function () {
var reason = process.env['PDFJS_UPDATE_REASON'];
safeSpawnSync('git', ['init'], { cwd: GH_PAGES_DIR, });
- safeSpawnSync('git', ['remote', 'add', 'origin', REPO], { cwd: GH_PAGES_DIR, });
+ safeSpawnSync('git', ['remote', 'add', 'origin', REPO],
+ { cwd: GH_PAGES_DIR, });
safeSpawnSync('git', ['add', '-A'], { cwd: GH_PAGES_DIR, });
safeSpawnSync('git', [
'commit', '-am', 'gh-pages site created via gulpfile.js script',
```
2017-06-03 00:13:35 +09:00
|
|
|
defines: bundleDefines,
|
|
|
|
},
|
2017-03-06 23:42:48 +09:00
|
|
|
},
|
Fix the remaining cases of inconsistent spacing and trailing commas in objects, and enable the `comma-dangle` and `object-curly-spacing` ESLint rules
http://eslint.org/docs/rules/comma-dangle
http://eslint.org/docs/rules/object-curly-spacing
*Please note:* This patch was created automatically, using the ESLint `--fix` command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch.
```diff
diff --git a/gulpfile.js b/gulpfile.js
index d18b9c58..7d47fd8d 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -1247,7 +1247,8 @@ gulp.task('gh-pages-git', ['gh-pages-prepare', 'wintersmith'], function () {
var reason = process.env['PDFJS_UPDATE_REASON'];
safeSpawnSync('git', ['init'], { cwd: GH_PAGES_DIR, });
- safeSpawnSync('git', ['remote', 'add', 'origin', REPO], { cwd: GH_PAGES_DIR, });
+ safeSpawnSync('git', ['remote', 'add', 'origin', REPO],
+ { cwd: GH_PAGES_DIR, });
safeSpawnSync('git', ['add', '-A'], { cwd: GH_PAGES_DIR, });
safeSpawnSync('git', [
'commit', '-am', 'gh-pages site created via gulpfile.js script',
```
2017-06-03 00:13:35 +09:00
|
|
|
],
|
|
|
|
},
|
2017-07-09 22:19:16 +09:00
|
|
|
// Avoid shadowing actual Node.js variables with polyfills, by disabling
|
|
|
|
// polyfills/mocks - https://webpack.js.org/configuration/node/
|
2017-09-30 04:42:31 +09:00
|
|
|
node: false,
|
2017-02-09 07:32:15 +09:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2020-03-25 17:42:50 +09:00
|
|
|
function webpack2Stream(webpackConfig) {
|
2017-02-09 07:32:15 +09:00
|
|
|
// Replacing webpack1 to webpack2 in the webpack-stream.
|
2020-03-25 17:42:50 +09:00
|
|
|
return webpackStream(webpackConfig, webpack2);
|
2016-04-23 07:20:47 +09:00
|
|
|
}
|
|
|
|
|
2017-02-07 23:53:33 +09:00
|
|
|
function getVersionJSON() {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return JSON.parse(fs.readFileSync(BUILD_DIR + "version.json").toString());
|
2017-02-07 23:53:33 +09:00
|
|
|
}
|
|
|
|
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
function checkChromePreferencesFile(chromePrefsPath, webPrefs) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const chromePrefs = JSON.parse(fs.readFileSync(chromePrefsPath).toString());
|
2021-03-19 00:26:55 +09:00
|
|
|
const chromePrefsKeys = Object.keys(chromePrefs.properties).filter(key => {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const description = chromePrefs.properties[key].description;
|
2018-02-17 09:09:17 +09:00
|
|
|
// Deprecated keys are allowed in the managed preferences file.
|
2023-06-27 01:46:37 +09:00
|
|
|
// The code maintainer is responsible for adding migration logic to
|
2018-02-17 09:09:17 +09:00
|
|
|
// extensions/chromium/options/migration.js and web/chromecom.js .
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return !description || !description.startsWith("DEPRECATED.");
|
2018-02-17 09:09:17 +09:00
|
|
|
});
|
2020-12-01 02:11:28 +09:00
|
|
|
|
|
|
|
let ret = true;
|
2023-06-27 01:46:37 +09:00
|
|
|
// Verify that every entry in webPrefs is also in preferences_schema.json.
|
|
|
|
for (const [key, value] of Object.entries(webPrefs)) {
|
|
|
|
if (!chromePrefsKeys.includes(key)) {
|
|
|
|
// Note: this would also reject keys that are present but marked as
|
|
|
|
// DEPRECATED. A key should not be marked as DEPRECATED if it is still
|
|
|
|
// listed in webPrefs.
|
2020-12-01 02:11:28 +09:00
|
|
|
ret = false;
|
|
|
|
console.log(
|
2023-06-27 01:46:37 +09:00
|
|
|
`Warning: ${chromePrefsPath} does not contain an entry for pref: ${key}`
|
2020-12-01 02:11:28 +09:00
|
|
|
);
|
2023-06-27 01:46:37 +09:00
|
|
|
} else if (chromePrefs.properties[key].default !== value) {
|
|
|
|
ret = false;
|
|
|
|
console.log(
|
|
|
|
`Warning: not the same values (for "${key}"): ` +
|
|
|
|
`${chromePrefs.properties[key].default} !== ${value}`
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Verify that preferences_schema.json does not contain entries that are not
|
|
|
|
// in webPrefs (app_options.js).
|
|
|
|
for (const key of chromePrefsKeys) {
|
|
|
|
if (!(key in webPrefs)) {
|
2020-12-01 02:11:28 +09:00
|
|
|
ret = false;
|
|
|
|
console.log(
|
2023-06-27 01:46:37 +09:00
|
|
|
`Warning: ${chromePrefsPath} contains an unrecognized pref: ${key}. ` +
|
|
|
|
`Remove it, or prepend "DEPRECATED. " and add migration logic to ` +
|
|
|
|
`extensions/chromium/options/migration.js and web/chromecom.js.`
|
2020-12-01 02:11:28 +09:00
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return ret;
|
2016-05-12 07:58:17 +09:00
|
|
|
}
|
|
|
|
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
function tweakWebpackOutput(jsName) {
|
|
|
|
const replacer = ["__non_webpack_import__\\("];
|
|
|
|
|
|
|
|
if (jsName) {
|
|
|
|
replacer.push(
|
|
|
|
" __webpack_exports__ = {};",
|
|
|
|
" __webpack_exports__ = await __webpack_exports__;"
|
|
|
|
);
|
|
|
|
}
|
|
|
|
const regex = new RegExp(`(${replacer.join("|")})`, "gm");
|
2016-04-23 07:20:47 +09:00
|
|
|
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
return replace(regex, match => {
|
|
|
|
switch (match) {
|
|
|
|
case "__non_webpack_import__(":
|
|
|
|
return "import(/* webpackIgnore: true */ ";
|
|
|
|
case " __webpack_exports__ = {};":
|
|
|
|
return ` __webpack_exports__ = globalThis.${jsName} = {};`;
|
|
|
|
case " __webpack_exports__ = await __webpack_exports__;":
|
|
|
|
return ` __webpack_exports__ = globalThis.${jsName} = await __webpack_exports__;`;
|
|
|
|
}
|
|
|
|
return match;
|
|
|
|
});
|
Convert `web/debugger.js` to a *basic* module
The various functionality in `web/debugger.js` is currently *indirectly* added to the global scope, since that's how `var` works when it's used outside of any functions/closures.
Given how this functionality is being accessed/used, not just in the viewer but also in the API and textLayer, simply converting the entire file to a module isn't trivial[1]. However, we can at least export the `PDFBug`-part properly and then `import` that dynamically in the viewer.
Also, to improve the code a little bit, we're now *explicitly* exporting the necessary functionality globally.
According to MDN, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility, all the browsers that we now support have dynamic `imports` implementations.
---
[1] We could probably pass around references to the necessary functionality, but given how this is being used I'm just not sure it's worth the effort. Also, adding *official* support for these viewer-specific debugging tools in the API feels both unnecessary and unfortunate.
2022-04-03 18:51:49 +09:00
|
|
|
}
|
|
|
|
|
2020-05-03 18:27:22 +09:00
|
|
|
function createMainBundle(defines) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const mainFileConfig = createWebpackConfig(defines, {
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
filename: "pdf.mjs",
|
|
|
|
library: {
|
|
|
|
type: "module",
|
|
|
|
},
|
2017-02-09 07:32:15 +09:00
|
|
|
});
|
2020-05-03 18:27:22 +09:00
|
|
|
return gulp
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
.src("./src/pdf.js")
|
2017-02-09 07:32:15 +09:00
|
|
|
.pipe(webpack2Stream(mainFileConfig))
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.pipe(tweakWebpackOutput("pdfjsLib"));
|
2020-05-03 18:27:22 +09:00
|
|
|
}
|
2017-02-09 07:32:15 +09:00
|
|
|
|
2020-12-04 23:49:13 +09:00
|
|
|
function createScriptingBundle(defines, extraOptions = undefined) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const scriptingFileConfig = createWebpackConfig(
|
2020-12-04 23:49:13 +09:00
|
|
|
defines,
|
|
|
|
{
|
2023-10-07 00:26:14 +09:00
|
|
|
filename: "pdf.scripting.mjs",
|
|
|
|
library: {
|
|
|
|
type: "module",
|
|
|
|
},
|
2020-12-04 23:49:13 +09:00
|
|
|
},
|
|
|
|
extraOptions
|
|
|
|
);
|
2020-10-01 20:57:23 +09:00
|
|
|
return gulp
|
2020-10-26 00:28:23 +09:00
|
|
|
.src("./src/pdf.scripting.js")
|
|
|
|
.pipe(webpack2Stream(scriptingFileConfig))
|
2023-10-07 00:26:14 +09:00
|
|
|
.pipe(tweakWebpackOutput());
|
2020-12-04 08:39:50 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
function createSandboxExternal(defines) {
|
|
|
|
const licenseHeader = fs.readFileSync("./src/license_header.js").toString();
|
|
|
|
|
|
|
|
const ctx = {
|
|
|
|
saveComments: false,
|
|
|
|
defines,
|
|
|
|
};
|
2023-03-27 18:40:58 +09:00
|
|
|
return gulp
|
|
|
|
.src("./src/pdf.sandbox.external.js")
|
|
|
|
.pipe(rename("pdf.sandbox.external.sys.mjs"))
|
|
|
|
.pipe(
|
|
|
|
transform("utf8", content => {
|
2023-07-08 23:07:54 +09:00
|
|
|
content = preprocessPDFJSCode(ctx, content);
|
2023-03-27 18:40:58 +09:00
|
|
|
return `${licenseHeader}\n${content}`;
|
|
|
|
})
|
|
|
|
);
|
2020-10-01 20:57:23 +09:00
|
|
|
}
|
|
|
|
|
2020-12-05 23:51:39 +09:00
|
|
|
function createTemporaryScriptingBundle(defines, extraOptions = undefined) {
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
return createScriptingBundle(defines, {
|
2020-12-05 23:51:39 +09:00
|
|
|
disableVersionInfo: !!(extraOptions && extraOptions.disableVersionInfo),
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
disableSourceMaps: true,
|
|
|
|
disableLicenseHeader: true,
|
|
|
|
}).pipe(gulp.dest(TMP_DIR));
|
|
|
|
}
|
|
|
|
|
|
|
|
function createSandboxBundle(defines, extraOptions = undefined) {
|
2023-10-07 00:26:14 +09:00
|
|
|
const scriptingPath = TMP_DIR + "pdf.scripting.mjs";
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
// Insert the source as a string to be `eval`-ed in the sandbox.
|
2023-10-18 20:32:50 +09:00
|
|
|
const sandboxDefines = {
|
|
|
|
...defines,
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
PDF_SCRIPTING_JS_SOURCE: fs.readFileSync(scriptingPath).toString(),
|
2023-10-18 20:32:50 +09:00
|
|
|
};
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
fs.unlinkSync(scriptingPath);
|
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const sandboxFileConfig = createWebpackConfig(
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
sandboxDefines,
|
|
|
|
{
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
filename: "pdf.sandbox.mjs",
|
|
|
|
library: {
|
|
|
|
type: "module",
|
|
|
|
},
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
},
|
|
|
|
extraOptions
|
|
|
|
);
|
2020-11-09 22:45:02 +09:00
|
|
|
|
2020-12-04 21:03:24 +09:00
|
|
|
return gulp
|
|
|
|
.src("./src/pdf.sandbox.js")
|
|
|
|
.pipe(webpack2Stream(sandboxFileConfig))
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.pipe(tweakWebpackOutput("pdfjsSandbox"));
|
2020-11-09 22:45:02 +09:00
|
|
|
}
|
|
|
|
|
2020-05-03 18:27:22 +09:00
|
|
|
function createWorkerBundle(defines) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const workerFileConfig = createWebpackConfig(defines, {
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
filename: "pdf.worker.mjs",
|
|
|
|
library: {
|
|
|
|
type: "module",
|
|
|
|
},
|
2017-02-09 07:32:15 +09:00
|
|
|
});
|
2020-05-03 18:27:22 +09:00
|
|
|
return gulp
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
.src("./src/pdf.worker.js")
|
2017-02-09 07:32:15 +09:00
|
|
|
.pipe(webpack2Stream(workerFileConfig))
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.pipe(tweakWebpackOutput("pdfjsWorker"));
|
2016-04-23 07:20:47 +09:00
|
|
|
}
|
|
|
|
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
function createWebBundle(defines, options) {
|
|
|
|
const viewerFileConfig = createWebpackConfig(
|
|
|
|
defines,
|
|
|
|
{
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
filename: "viewer.mjs",
|
|
|
|
library: {
|
|
|
|
type: "module",
|
|
|
|
},
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
},
|
|
|
|
{
|
|
|
|
defaultPreferencesDir: options.defaultPreferencesDir,
|
|
|
|
}
|
|
|
|
);
|
Convert `web/debugger.js` to a *basic* module
The various functionality in `web/debugger.js` is currently *indirectly* added to the global scope, since that's how `var` works when it's used outside of any functions/closures.
Given how this functionality is being accessed/used, not just in the viewer but also in the API and textLayer, simply converting the entire file to a module isn't trivial[1]. However, we can at least export the `PDFBug`-part properly and then `import` that dynamically in the viewer.
Also, to improve the code a little bit, we're now *explicitly* exporting the necessary functionality globally.
According to MDN, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility, all the browsers that we now support have dynamic `imports` implementations.
---
[1] We could probably pass around references to the necessary functionality, but given how this is being used I'm just not sure it's worth the effort. Also, adding *official* support for these viewer-specific debugging tools in the API feels both unnecessary and unfortunate.
2022-04-03 18:51:49 +09:00
|
|
|
return gulp
|
|
|
|
.src("./web/viewer.js")
|
|
|
|
.pipe(webpack2Stream(viewerFileConfig))
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.pipe(tweakWebpackOutput());
|
2017-02-09 07:32:15 +09:00
|
|
|
}
|
|
|
|
|
2022-12-15 00:40:25 +09:00
|
|
|
function createGVWebBundle(defines, options) {
|
|
|
|
const viewerFileConfig = createWebpackConfig(
|
|
|
|
defines,
|
|
|
|
{
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
filename: "viewer-geckoview.mjs",
|
|
|
|
library: {
|
|
|
|
type: "module",
|
|
|
|
},
|
2022-12-15 00:40:25 +09:00
|
|
|
},
|
|
|
|
{
|
|
|
|
defaultPreferencesDir: options.defaultPreferencesDir,
|
|
|
|
}
|
|
|
|
);
|
|
|
|
return gulp
|
|
|
|
.src("./web/viewer-geckoview.js")
|
|
|
|
.pipe(webpack2Stream(viewerFileConfig))
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.pipe(tweakWebpackOutput());
|
2022-12-15 00:40:25 +09:00
|
|
|
}
|
|
|
|
|
2017-02-09 07:32:15 +09:00
|
|
|
function createComponentsBundle(defines) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const componentsFileConfig = createWebpackConfig(defines, {
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
filename: "pdf_viewer.mjs",
|
|
|
|
library: {
|
|
|
|
type: "module",
|
|
|
|
},
|
2017-02-09 07:32:15 +09:00
|
|
|
});
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return gulp
|
|
|
|
.src("./web/pdf_viewer.component.js")
|
2017-02-09 07:32:15 +09:00
|
|
|
.pipe(webpack2Stream(componentsFileConfig))
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.pipe(tweakWebpackOutput("pdfjsViewer"));
|
2016-04-23 07:20:47 +09:00
|
|
|
}
|
|
|
|
|
Add a `gulp image_decoders` command to allow packaging/distributing the image decoders (i.e. jpg.js, jpx.js, jbig2.js) separately from the main PDF.js library
Please note that the standalone `pdf.image_decoders.js` file will be including the complete `src/shared/util.js` file, despite only using parts of it.[1] This was done *purposely*, to not negatively impact the readability/maintainability of the core PDF.js code.
Furthermore, to ensure that the compatibility is the same in the regular PDF.js library *and* in the the standalone image decoders, `src/shared/compatibility.js` was included as well.
To (hopefully) prevent future complaints about the size of the built `pdf.image_decoders.js` file, a few existing async-related polyfills are being skipped (since all of the image decoders are completely synchronous).
Obviously this required adding a couple of pre-processor statements, but given that these are all limited to "compatibility" code, I think this might be OK!?
---
[1] However, please note that previous commits moved `PageViewport` and `MessageHandler` out of `src/shared/util.js` which reduced its size.
2018-05-16 20:49:26 +09:00
|
|
|
function createImageDecodersBundle(defines) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const componentsFileConfig = createWebpackConfig(defines, {
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
filename: "pdf.image_decoders.mjs",
|
|
|
|
library: {
|
|
|
|
type: "module",
|
|
|
|
},
|
Add a `gulp image_decoders` command to allow packaging/distributing the image decoders (i.e. jpg.js, jpx.js, jbig2.js) separately from the main PDF.js library
Please note that the standalone `pdf.image_decoders.js` file will be including the complete `src/shared/util.js` file, despite only using parts of it.[1] This was done *purposely*, to not negatively impact the readability/maintainability of the core PDF.js code.
Furthermore, to ensure that the compatibility is the same in the regular PDF.js library *and* in the the standalone image decoders, `src/shared/compatibility.js` was included as well.
To (hopefully) prevent future complaints about the size of the built `pdf.image_decoders.js` file, a few existing async-related polyfills are being skipped (since all of the image decoders are completely synchronous).
Obviously this required adding a couple of pre-processor statements, but given that these are all limited to "compatibility" code, I think this might be OK!?
---
[1] However, please note that previous commits moved `PageViewport` and `MessageHandler` out of `src/shared/util.js` which reduced its size.
2018-05-16 20:49:26 +09:00
|
|
|
});
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return gulp
|
|
|
|
.src("./src/pdf.image_decoders.js")
|
Add a `gulp image_decoders` command to allow packaging/distributing the image decoders (i.e. jpg.js, jpx.js, jbig2.js) separately from the main PDF.js library
Please note that the standalone `pdf.image_decoders.js` file will be including the complete `src/shared/util.js` file, despite only using parts of it.[1] This was done *purposely*, to not negatively impact the readability/maintainability of the core PDF.js code.
Furthermore, to ensure that the compatibility is the same in the regular PDF.js library *and* in the the standalone image decoders, `src/shared/compatibility.js` was included as well.
To (hopefully) prevent future complaints about the size of the built `pdf.image_decoders.js` file, a few existing async-related polyfills are being skipped (since all of the image decoders are completely synchronous).
Obviously this required adding a couple of pre-processor statements, but given that these are all limited to "compatibility" code, I think this might be OK!?
---
[1] However, please note that previous commits moved `PageViewport` and `MessageHandler` out of `src/shared/util.js` which reduced its size.
2018-05-16 20:49:26 +09:00
|
|
|
.pipe(webpack2Stream(componentsFileConfig))
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.pipe(tweakWebpackOutput("pdfjsImageDecoders"));
|
Add a `gulp image_decoders` command to allow packaging/distributing the image decoders (i.e. jpg.js, jpx.js, jbig2.js) separately from the main PDF.js library
Please note that the standalone `pdf.image_decoders.js` file will be including the complete `src/shared/util.js` file, despite only using parts of it.[1] This was done *purposely*, to not negatively impact the readability/maintainability of the core PDF.js code.
Furthermore, to ensure that the compatibility is the same in the regular PDF.js library *and* in the the standalone image decoders, `src/shared/compatibility.js` was included as well.
To (hopefully) prevent future complaints about the size of the built `pdf.image_decoders.js` file, a few existing async-related polyfills are being skipped (since all of the image decoders are completely synchronous).
Obviously this required adding a couple of pre-processor statements, but given that these are all limited to "compatibility" code, I think this might be OK!?
---
[1] However, please note that previous commits moved `PageViewport` and `MessageHandler` out of `src/shared/util.js` which reduced its size.
2018-05-16 20:49:26 +09:00
|
|
|
}
|
|
|
|
|
2021-06-10 06:50:50 +09:00
|
|
|
function createCMapBundle() {
|
|
|
|
return gulp.src(["external/bcmaps/*.bcmap", "external/bcmaps/LICENSE"], {
|
|
|
|
base: "external/bcmaps",
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
function createStandardFontBundle() {
|
|
|
|
return gulp.src(
|
|
|
|
[
|
|
|
|
"external/standard_fonts/*.pfb",
|
|
|
|
"external/standard_fonts/*.ttf",
|
|
|
|
"external/standard_fonts/LICENSE_FOXIT",
|
|
|
|
"external/standard_fonts/LICENSE_LIBERATION",
|
|
|
|
],
|
|
|
|
{
|
|
|
|
base: "external/standard_fonts",
|
|
|
|
}
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2020-03-25 17:42:50 +09:00
|
|
|
function checkFile(filePath) {
|
2016-05-02 23:58:29 +09:00
|
|
|
try {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const stat = fs.lstatSync(filePath);
|
2016-05-02 23:58:29 +09:00
|
|
|
return stat.isFile();
|
2023-06-12 18:46:11 +09:00
|
|
|
} catch {
|
2016-05-02 23:58:29 +09:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-25 17:42:50 +09:00
|
|
|
function checkDir(dirPath) {
|
2017-01-11 02:50:38 +09:00
|
|
|
try {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const stat = fs.lstatSync(dirPath);
|
2017-01-11 02:50:38 +09:00
|
|
|
return stat.isDirectory();
|
2023-06-12 18:46:11 +09:00
|
|
|
} catch {
|
2017-01-11 02:50:38 +09:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-25 17:42:50 +09:00
|
|
|
function replaceInFile(filePath, find, replacement) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
let content = fs.readFileSync(filePath).toString();
|
2017-04-15 04:28:46 +09:00
|
|
|
content = content.replace(find, replacement);
|
2020-03-25 17:42:50 +09:00
|
|
|
fs.writeFileSync(filePath, content);
|
2017-04-15 04:28:46 +09:00
|
|
|
}
|
|
|
|
|
2017-02-04 23:19:46 +09:00
|
|
|
function getTempFile(prefix, suffix) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
mkdirp.sync(BUILD_DIR + "tmp/");
|
2023-07-08 22:33:03 +09:00
|
|
|
const bytes = crypto.randomBytes(6).toString("hex");
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const filePath = BUILD_DIR + "tmp/" + prefix + bytes + suffix;
|
2020-03-25 17:42:50 +09:00
|
|
|
fs.writeFileSync(filePath, "");
|
|
|
|
return filePath;
|
2017-02-04 23:19:46 +09:00
|
|
|
}
|
|
|
|
|
2021-08-02 23:37:42 +09:00
|
|
|
function createTestSource(testsName, { bot = false, xfaOnly = false } = {}) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const source = stream.Readable({ objectMode: true });
|
2020-04-14 19:28:14 +09:00
|
|
|
source._read = function () {
|
2016-05-02 23:58:29 +09:00
|
|
|
console.log();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log("### Running " + testsName + " tests");
|
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const PDF_TEST = process.env.PDF_TEST || "test_manifest.json";
|
2022-01-19 20:02:05 +09:00
|
|
|
let forceNoChrome = false;
|
2023-07-08 19:44:37 +09:00
|
|
|
const args = ["test.mjs"];
|
2016-05-02 23:58:29 +09:00
|
|
|
switch (testsName) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "browser":
|
2021-08-02 23:37:42 +09:00
|
|
|
if (!bot) {
|
|
|
|
args.push("--reftest");
|
2022-01-19 20:02:05 +09:00
|
|
|
} else {
|
|
|
|
const os = process.env.OS;
|
|
|
|
if (/windows/i.test(os)) {
|
|
|
|
// The browser-tests are too slow in Google Chrome on the Windows
|
|
|
|
// bot, causing a timeout, hence disabling them for now.
|
|
|
|
forceNoChrome = true;
|
|
|
|
}
|
2021-08-02 23:37:42 +09:00
|
|
|
}
|
|
|
|
if (xfaOnly) {
|
|
|
|
args.push("--xfaOnly");
|
|
|
|
}
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
args.push("--manifestFile=" + PDF_TEST);
|
2016-05-02 23:58:29 +09:00
|
|
|
break;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "unit":
|
|
|
|
args.push("--unitTest");
|
2016-05-02 23:58:29 +09:00
|
|
|
break;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "font":
|
|
|
|
args.push("--fontTest");
|
2016-05-02 23:58:29 +09:00
|
|
|
break;
|
2020-12-01 02:11:28 +09:00
|
|
|
case "integration":
|
|
|
|
args.push("--integration");
|
|
|
|
break;
|
2016-05-02 23:58:29 +09:00
|
|
|
default:
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.emit("error", new Error("Unknown name: " + testsName));
|
2016-05-02 23:58:29 +09:00
|
|
|
return null;
|
|
|
|
}
|
2018-08-04 09:48:47 +09:00
|
|
|
if (bot) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
args.push("--strictVerify");
|
2018-08-04 09:48:47 +09:00
|
|
|
}
|
2022-01-19 20:02:05 +09:00
|
|
|
if (process.argv.includes("--noChrome") || forceNoChrome) {
|
2020-04-19 06:04:28 +09:00
|
|
|
args.push("--noChrome");
|
|
|
|
}
|
2016-05-02 23:58:29 +09:00
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const testProcess = startNode(args, { cwd: TEST_DIR, stdio: "inherit" });
|
2020-04-14 19:28:14 +09:00
|
|
|
testProcess.on("close", function (code) {
|
2016-05-02 23:58:29 +09:00
|
|
|
source.push(null);
|
|
|
|
});
|
2019-05-10 19:54:06 +09:00
|
|
|
return undefined;
|
2016-05-02 23:58:29 +09:00
|
|
|
};
|
|
|
|
return source;
|
|
|
|
}
|
|
|
|
|
2018-08-04 09:48:47 +09:00
|
|
|
function makeRef(done, bot) {
|
2017-02-25 08:12:02 +09:00
|
|
|
console.log();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log("### Creating reference images");
|
2017-02-25 08:12:02 +09:00
|
|
|
|
2022-01-31 02:24:22 +09:00
|
|
|
let forceNoChrome = false;
|
2023-07-08 19:44:37 +09:00
|
|
|
const args = ["test.mjs", "--masterMode"];
|
2018-08-04 09:48:47 +09:00
|
|
|
if (bot) {
|
2022-01-31 02:24:22 +09:00
|
|
|
const os = process.env.OS;
|
|
|
|
if (/windows/i.test(os)) {
|
|
|
|
// The browser-tests are too slow in Google Chrome on the Windows
|
|
|
|
// bot, causing a timeout, hence disabling them for now.
|
|
|
|
forceNoChrome = true;
|
|
|
|
}
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
args.push("--noPrompts", "--strictVerify");
|
2017-02-25 08:12:02 +09:00
|
|
|
}
|
2022-01-31 02:24:22 +09:00
|
|
|
if (process.argv.includes("--noChrome") || forceNoChrome) {
|
2020-04-19 06:04:28 +09:00
|
|
|
args.push("--noChrome");
|
|
|
|
}
|
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const testProcess = startNode(args, { cwd: TEST_DIR, stdio: "inherit" });
|
2020-04-14 19:28:14 +09:00
|
|
|
testProcess.on("close", function (code) {
|
2017-02-25 08:12:02 +09:00
|
|
|
done();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2020-04-14 19:28:14 +09:00
|
|
|
gulp.task("default", function (done) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log("Available tasks:");
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const tasks = Object.keys(gulp.registry().tasks());
|
2021-06-04 19:30:09 +09:00
|
|
|
for (const taskName of tasks.sort()) {
|
|
|
|
if (taskName.endsWith("-pre")) {
|
|
|
|
continue;
|
|
|
|
}
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log(" " + taskName);
|
2021-06-04 19:30:09 +09:00
|
|
|
}
|
2018-11-19 02:33:23 +09:00
|
|
|
done();
|
2016-03-05 00:36:46 +09:00
|
|
|
});
|
|
|
|
|
2021-06-04 19:30:09 +09:00
|
|
|
function createBuildNumber(done) {
|
2016-04-23 07:20:47 +09:00
|
|
|
console.log();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log("### Getting extension build number");
|
2016-04-23 07:20:47 +09:00
|
|
|
|
2020-11-29 17:59:03 +09:00
|
|
|
exec(
|
|
|
|
"git log --format=oneline " + config.baseVersion + "..",
|
|
|
|
function (err, stdout, stderr) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
let buildNumber = 0;
|
2020-11-29 17:59:03 +09:00
|
|
|
if (!err) {
|
|
|
|
// Build number is the number of commits since base version
|
|
|
|
buildNumber = stdout ? stdout.match(/\n/g).length : 0;
|
|
|
|
} else {
|
|
|
|
console.log(
|
|
|
|
"This is not a Git repository; using default build number."
|
|
|
|
);
|
2016-04-23 07:20:47 +09:00
|
|
|
}
|
|
|
|
|
2020-11-29 17:59:03 +09:00
|
|
|
console.log("Extension build number: " + buildNumber);
|
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const version = config.versionPrefix + buildNumber;
|
2020-11-29 17:59:03 +09:00
|
|
|
|
|
|
|
exec('git log --format="%h" -n 1', function (err2, stdout2, stderr2) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
let buildCommit = "";
|
2020-11-29 17:59:03 +09:00
|
|
|
if (!err2) {
|
|
|
|
buildCommit = stdout2.replace("\n", "");
|
|
|
|
}
|
|
|
|
|
|
|
|
createStringSource(
|
|
|
|
"version.json",
|
|
|
|
JSON.stringify(
|
|
|
|
{
|
2021-01-23 01:38:26 +09:00
|
|
|
version,
|
2020-11-29 17:59:03 +09:00
|
|
|
build: buildNumber,
|
|
|
|
commit: buildCommit,
|
|
|
|
},
|
|
|
|
null,
|
|
|
|
2
|
|
|
|
)
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
)
|
2020-11-29 17:59:03 +09:00
|
|
|
.pipe(gulp.dest(BUILD_DIR))
|
|
|
|
.on("end", done);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
);
|
2021-06-04 19:30:09 +09:00
|
|
|
}
|
2016-04-23 07:20:47 +09:00
|
|
|
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
function buildDefaultPreferences(defines, dir) {
|
2019-02-13 22:00:23 +09:00
|
|
|
console.log();
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
console.log("### Building default preferences");
|
|
|
|
|
2023-10-18 20:32:50 +09:00
|
|
|
const bundleDefines = {
|
|
|
|
...defines,
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
LIB: true,
|
2023-06-25 23:02:31 +09:00
|
|
|
TESTING: defines.TESTING ?? process.env.TESTING === "true",
|
2023-10-18 20:32:50 +09:00
|
|
|
};
|
2019-02-13 22:00:23 +09:00
|
|
|
|
2023-07-09 18:37:00 +09:00
|
|
|
const defaultPreferencesConfig = createWebpackConfig(
|
2021-03-20 21:06:38 +09:00
|
|
|
bundleDefines,
|
2023-07-09 18:37:00 +09:00
|
|
|
{
|
|
|
|
filename: "app_options.mjs",
|
|
|
|
library: {
|
|
|
|
type: "module",
|
|
|
|
},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
disableVersionInfo: true,
|
|
|
|
}
|
2021-03-20 21:06:38 +09:00
|
|
|
);
|
2023-07-09 18:37:00 +09:00
|
|
|
return gulp
|
|
|
|
.src("web/app_options.js")
|
|
|
|
.pipe(webpack2Stream(defaultPreferencesConfig))
|
|
|
|
.pipe(gulp.dest(DEFAULT_PREFERENCES_DIR + dir));
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
}
|
2019-02-13 22:00:23 +09:00
|
|
|
|
2023-07-09 18:37:00 +09:00
|
|
|
async function parseDefaultPreferences(dir) {
|
|
|
|
console.log();
|
|
|
|
console.log("### Parsing default preferences");
|
|
|
|
|
|
|
|
// eslint-disable-next-line no-unsanitized/method
|
|
|
|
const { AppOptions, OptionKind } = await import(
|
|
|
|
"./" + DEFAULT_PREFERENCES_DIR + dir + "app_options.mjs"
|
|
|
|
);
|
|
|
|
|
|
|
|
const prefs = AppOptions.getAll(OptionKind.PREFERENCE);
|
|
|
|
if (Object.keys(prefs).length === 0) {
|
|
|
|
throw new Error("No default preferences found.");
|
|
|
|
}
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
|
2023-07-09 18:37:00 +09:00
|
|
|
fs.writeFileSync(
|
|
|
|
DEFAULT_PREFERENCES_DIR + dir + "default_preferences.json",
|
|
|
|
JSON.stringify(prefs)
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
function getDefaultPreferences(dir) {
|
|
|
|
const str = fs
|
|
|
|
.readFileSync(DEFAULT_PREFERENCES_DIR + dir + "default_preferences.json")
|
|
|
|
.toString();
|
|
|
|
return JSON.parse(str);
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
}
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
2020-04-14 19:28:14 +09:00
|
|
|
gulp.task("locale", function () {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const VIEWER_LOCALE_OUTPUT = "web/locale/";
|
2017-01-11 02:50:38 +09:00
|
|
|
|
|
|
|
console.log();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log("### Building localization files");
|
2017-01-11 02:50:38 +09:00
|
|
|
|
|
|
|
rimraf.sync(VIEWER_LOCALE_OUTPUT);
|
|
|
|
mkdirp.sync(VIEWER_LOCALE_OUTPUT);
|
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const subfolders = fs.readdirSync(L10N_DIR);
|
2017-01-11 02:50:38 +09:00
|
|
|
subfolders.sort();
|
2023-10-13 23:23:17 +09:00
|
|
|
const viewerOutput = Object.create(null);
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const locales = [];
|
2022-07-17 22:48:39 +09:00
|
|
|
for (const locale of subfolders) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const dirPath = L10N_DIR + locale;
|
2020-03-25 17:42:50 +09:00
|
|
|
if (!checkDir(dirPath)) {
|
2017-01-11 02:50:38 +09:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!/^[a-z][a-z]([a-z])?(-[A-Z][A-Z])?$/.test(locale)) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log("Skipping invalid locale: " + locale);
|
2017-01-11 02:50:38 +09:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
mkdirp.sync(VIEWER_LOCALE_OUTPUT + "/" + locale);
|
2017-01-11 02:50:38 +09:00
|
|
|
|
|
|
|
locales.push(locale);
|
|
|
|
|
2023-10-13 23:23:17 +09:00
|
|
|
if (checkFile(dirPath + "/viewer.ftl")) {
|
|
|
|
viewerOutput[locale] = `${locale}/viewer.ftl`;
|
2017-01-11 02:50:38 +09:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-10-13 23:23:17 +09:00
|
|
|
const glob = locales.length === 1 ? locales[0] : `{${locales.join(",")}}`;
|
|
|
|
|
2017-01-11 02:50:38 +09:00
|
|
|
return merge([
|
2023-10-13 23:23:17 +09:00
|
|
|
createStringSource("locale.json", JSON.stringify(viewerOutput)).pipe(
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.dest(VIEWER_LOCALE_OUTPUT)
|
|
|
|
),
|
|
|
|
gulp
|
2023-10-13 23:23:17 +09:00
|
|
|
.src(`${L10N_DIR}/${glob}/viewer.ftl`, {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
base: L10N_DIR,
|
|
|
|
})
|
2017-01-11 02:50:38 +09:00
|
|
|
.pipe(gulp.dest(VIEWER_LOCALE_OUTPUT)),
|
|
|
|
]);
|
|
|
|
});
|
|
|
|
|
2023-07-08 21:35:15 +09:00
|
|
|
gulp.task("cmaps", async function () {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const CMAP_INPUT = "external/cmaps";
|
|
|
|
const VIEWER_CMAP_OUTPUT = "external/bcmaps";
|
2017-01-11 02:50:38 +09:00
|
|
|
|
|
|
|
console.log();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log("### Building cmaps");
|
2017-01-11 02:50:38 +09:00
|
|
|
|
|
|
|
// Testing a file that usually present.
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
if (!checkFile(CMAP_INPUT + "/UniJIS-UCS2-H")) {
|
|
|
|
console.log("./external/cmaps has no cmap files, download them from:");
|
|
|
|
console.log(" https://github.com/adobe-type-tools/cmap-resources");
|
|
|
|
throw new Error("cmap files were not found");
|
2017-01-11 02:50:38 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
// Remove old bcmap files.
|
2020-04-14 19:28:14 +09:00
|
|
|
fs.readdirSync(VIEWER_CMAP_OUTPUT).forEach(function (file) {
|
2017-01-11 02:50:38 +09:00
|
|
|
if (/\.bcmap$/i.test(file)) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
fs.unlinkSync(VIEWER_CMAP_OUTPUT + "/" + file);
|
2017-01-11 02:50:38 +09:00
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2023-07-08 21:35:15 +09:00
|
|
|
const { compressCmaps } = await import(
|
|
|
|
"./external/cmapscompress/compress.mjs"
|
|
|
|
);
|
2017-01-11 02:50:38 +09:00
|
|
|
compressCmaps(CMAP_INPUT, VIEWER_CMAP_OUTPUT, true);
|
|
|
|
});
|
|
|
|
|
2022-03-15 21:53:49 +09:00
|
|
|
function preprocessCSS(source, defines) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const outName = getTempFile("~preprocess", ".css");
|
2023-10-18 20:32:50 +09:00
|
|
|
preprocess(source, outName, defines);
|
2023-09-23 01:27:08 +09:00
|
|
|
const out = fs.readFileSync(outName).toString();
|
2017-02-04 23:19:46 +09:00
|
|
|
fs.unlinkSync(outName);
|
2022-03-14 21:55:05 +09:00
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const i = source.lastIndexOf("/");
|
2017-02-04 23:19:46 +09:00
|
|
|
return createStringSource(source.substr(i + 1), out);
|
|
|
|
}
|
|
|
|
|
2023-09-23 01:27:08 +09:00
|
|
|
function discardCommentsCSS() {
|
|
|
|
let copyrightNum = 0;
|
|
|
|
|
|
|
|
function remove(comment) {
|
|
|
|
// Remove all comments, except the *first* license header.
|
|
|
|
if (comment.startsWith("Copyright") && copyrightNum++ === 0) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return postcssDiscardComments({ remove });
|
|
|
|
}
|
|
|
|
|
2017-02-04 23:19:46 +09:00
|
|
|
function preprocessHTML(source, defines) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const outName = getTempFile("~preprocess", ".html");
|
2023-10-18 20:32:50 +09:00
|
|
|
preprocess(source, outName, defines);
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const out = fs.readFileSync(outName).toString();
|
2017-02-04 23:19:46 +09:00
|
|
|
fs.unlinkSync(outName);
|
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const i = source.lastIndexOf("/");
|
2021-02-24 11:00:05 +09:00
|
|
|
return createStringSource(source.substr(i + 1), `${out.trimEnd()}\n`);
|
2017-02-04 23:19:46 +09:00
|
|
|
}
|
|
|
|
|
2019-10-15 04:19:31 +09:00
|
|
|
function buildGeneric(defines, dir) {
|
|
|
|
rimraf.sync(dir);
|
|
|
|
|
|
|
|
return merge([
|
2020-05-03 18:27:22 +09:00
|
|
|
createMainBundle(defines).pipe(gulp.dest(dir + "build")),
|
|
|
|
createWorkerBundle(defines).pipe(gulp.dest(dir + "build")),
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
createSandboxBundle(defines).pipe(gulp.dest(dir + "build")),
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
createWebBundle(defines, {
|
|
|
|
defaultPreferencesDir: defines.SKIP_BABEL
|
|
|
|
? "generic/"
|
|
|
|
: "generic-legacy/",
|
|
|
|
}).pipe(gulp.dest(dir + "web")),
|
2019-10-15 04:19:31 +09:00
|
|
|
gulp.src(COMMON_WEB_FILES, { base: "web/" }).pipe(gulp.dest(dir + "web")),
|
|
|
|
gulp.src("LICENSE").pipe(gulp.dest(dir)),
|
|
|
|
gulp
|
2023-10-13 23:23:17 +09:00
|
|
|
.src(["web/locale/*/viewer.ftl", "web/locale/locale.json"], {
|
2019-10-15 04:19:31 +09:00
|
|
|
base: "web/",
|
|
|
|
})
|
|
|
|
.pipe(gulp.dest(dir + "web")),
|
2021-06-10 06:50:50 +09:00
|
|
|
createCMapBundle().pipe(gulp.dest(dir + "web/cmaps")),
|
|
|
|
createStandardFontBundle().pipe(gulp.dest(dir + "web/standard_fonts")),
|
|
|
|
|
2019-10-15 04:19:31 +09:00
|
|
|
preprocessHTML("web/viewer.html", defines).pipe(gulp.dest(dir + "web")),
|
2022-03-15 21:53:49 +09:00
|
|
|
preprocessCSS("web/viewer.css", defines)
|
2022-03-14 02:30:51 +09:00
|
|
|
.pipe(
|
2023-08-05 01:21:27 +09:00
|
|
|
postcss([
|
|
|
|
postcssDirPseudoClass(),
|
2023-09-23 01:27:08 +09:00
|
|
|
discardCommentsCSS(),
|
2023-08-05 01:21:27 +09:00
|
|
|
postcssNesting(),
|
|
|
|
autoprefixer(AUTOPREFIXER_CONFIG),
|
|
|
|
])
|
2022-03-14 02:30:51 +09:00
|
|
|
)
|
2019-10-15 04:19:31 +09:00
|
|
|
.pipe(gulp.dest(dir + "web")),
|
|
|
|
|
|
|
|
gulp
|
|
|
|
.src("web/compressed.tracemonkey-pldi-09.pdf")
|
|
|
|
.pipe(gulp.dest(dir + "web")),
|
|
|
|
]);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Builds the generic production viewer that is only compatible with up-to-date
|
|
|
|
// HTML5 browsers, which implement modern ECMAScript features.
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"generic",
|
2020-11-09 22:45:02 +09:00
|
|
|
gulp.series(
|
2021-06-04 19:30:09 +09:00
|
|
|
createBuildNumber,
|
2020-11-09 22:45:02 +09:00
|
|
|
"locale",
|
2021-06-03 22:44:17 +09:00
|
|
|
function scriptingGeneric() {
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, GENERIC: true };
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
return merge([
|
|
|
|
buildDefaultPreferences(defines, "generic/"),
|
|
|
|
createTemporaryScriptingBundle(defines),
|
|
|
|
]);
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
},
|
2023-07-09 18:37:00 +09:00
|
|
|
async function prefsGeneric() {
|
|
|
|
await parseDefaultPreferences("generic/");
|
|
|
|
},
|
2021-06-03 22:44:17 +09:00
|
|
|
function createGeneric() {
|
2020-11-09 22:45:02 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Creating generic viewer");
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, GENERIC: true };
|
2020-11-09 22:45:02 +09:00
|
|
|
|
|
|
|
return buildGeneric(defines, GENERIC_DIR);
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
}
|
2020-11-09 22:45:02 +09:00
|
|
|
)
|
2019-10-15 04:19:31 +09:00
|
|
|
);
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
2019-10-15 04:19:31 +09:00
|
|
|
// Builds the generic production viewer that should be compatible with most
|
|
|
|
// older HTML5 browsers.
|
|
|
|
gulp.task(
|
2021-02-10 02:28:48 +09:00
|
|
|
"generic-legacy",
|
2020-11-09 22:45:02 +09:00
|
|
|
gulp.series(
|
2021-06-04 19:30:09 +09:00
|
|
|
createBuildNumber,
|
2020-11-09 22:45:02 +09:00
|
|
|
"locale",
|
2021-06-03 22:44:17 +09:00
|
|
|
function scriptingGenericLegacy() {
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, GENERIC: true, SKIP_BABEL: false };
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
return merge([
|
|
|
|
buildDefaultPreferences(defines, "generic-legacy/"),
|
|
|
|
createTemporaryScriptingBundle(defines),
|
|
|
|
]);
|
2020-11-09 22:45:02 +09:00
|
|
|
},
|
2023-07-09 18:37:00 +09:00
|
|
|
async function prefsGenericLegacy() {
|
|
|
|
await parseDefaultPreferences("generic-legacy/");
|
|
|
|
},
|
2021-06-03 22:44:17 +09:00
|
|
|
function createGenericLegacy() {
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
console.log();
|
2021-02-10 02:28:48 +09:00
|
|
|
console.log("### Creating generic (legacy) viewer");
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, GENERIC: true, SKIP_BABEL: false };
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
|
2021-02-10 02:28:48 +09:00
|
|
|
return buildGeneric(defines, GENERIC_LEGACY_DIR);
|
2020-11-09 22:45:02 +09:00
|
|
|
}
|
|
|
|
)
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
|
|
|
|
2019-10-15 04:19:31 +09:00
|
|
|
function buildComponents(defines, dir) {
|
|
|
|
rimraf.sync(dir);
|
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const COMPONENTS_IMAGES = [
|
2019-10-15 04:19:31 +09:00
|
|
|
"web/images/annotation-*.svg",
|
|
|
|
"web/images/loading-icon.gif",
|
2023-10-01 23:47:34 +09:00
|
|
|
"web/images/altText_*.svg",
|
2019-10-15 04:19:31 +09:00
|
|
|
];
|
|
|
|
|
|
|
|
return merge([
|
|
|
|
createComponentsBundle(defines).pipe(gulp.dest(dir)),
|
|
|
|
gulp.src(COMPONENTS_IMAGES).pipe(gulp.dest(dir + "images")),
|
2022-03-15 21:53:49 +09:00
|
|
|
preprocessCSS("web/pdf_viewer.css", defines)
|
2022-03-14 02:30:51 +09:00
|
|
|
.pipe(
|
2023-08-05 01:21:27 +09:00
|
|
|
postcss([
|
|
|
|
postcssDirPseudoClass(),
|
2023-09-23 01:27:08 +09:00
|
|
|
discardCommentsCSS(),
|
2023-08-05 01:21:27 +09:00
|
|
|
postcssNesting(),
|
|
|
|
autoprefixer(AUTOPREFIXER_CONFIG),
|
|
|
|
])
|
2022-03-14 02:30:51 +09:00
|
|
|
)
|
2019-10-15 04:19:31 +09:00
|
|
|
.pipe(gulp.dest(dir)),
|
|
|
|
]);
|
|
|
|
}
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"components",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(createBuildNumber, function createComponents() {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Creating generic components");
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, COMPONENTS: true, GENERIC: true };
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
2019-10-15 04:19:31 +09:00
|
|
|
return buildComponents(defines, COMPONENTS_DIR);
|
|
|
|
})
|
|
|
|
);
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
2019-10-15 04:19:31 +09:00
|
|
|
gulp.task(
|
2021-02-10 02:28:48 +09:00
|
|
|
"components-legacy",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(createBuildNumber, function createComponentsLegacy() {
|
2019-10-15 04:19:31 +09:00
|
|
|
console.log();
|
2021-02-10 02:28:48 +09:00
|
|
|
console.log("### Creating generic (legacy) components");
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = {
|
|
|
|
...DEFINES,
|
2019-10-15 04:19:31 +09:00
|
|
|
COMPONENTS: true,
|
|
|
|
GENERIC: true,
|
|
|
|
SKIP_BABEL: false,
|
2023-10-18 20:32:50 +09:00
|
|
|
};
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
2021-02-10 02:28:48 +09:00
|
|
|
return buildComponents(defines, COMPONENTS_LEGACY_DIR);
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
})
|
|
|
|
);
|
2016-04-23 07:20:47 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"image_decoders",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(createBuildNumber, function createImageDecoders() {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Creating image decoders");
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, GENERIC: true, IMAGE_DECODERS: true };
|
2017-02-04 23:19:46 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return createImageDecodersBundle(defines).pipe(
|
|
|
|
gulp.dest(IMAGE_DECODERS_DIR)
|
|
|
|
);
|
|
|
|
})
|
|
|
|
);
|
2017-02-04 23:19:46 +09:00
|
|
|
|
2020-08-17 21:30:09 +09:00
|
|
|
gulp.task(
|
2021-02-10 02:28:48 +09:00
|
|
|
"image_decoders-legacy",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(createBuildNumber, function createImageDecodersLegacy() {
|
2020-08-17 21:30:09 +09:00
|
|
|
console.log();
|
2021-02-10 02:28:48 +09:00
|
|
|
console.log("### Creating (legacy) image decoders");
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = {
|
|
|
|
...DEFINES,
|
2020-08-17 21:30:09 +09:00
|
|
|
GENERIC: true,
|
|
|
|
IMAGE_DECODERS: true,
|
|
|
|
SKIP_BABEL: false,
|
2023-10-18 20:32:50 +09:00
|
|
|
};
|
2020-08-17 21:30:09 +09:00
|
|
|
|
|
|
|
return createImageDecodersBundle(defines).pipe(
|
2021-02-10 02:28:48 +09:00
|
|
|
gulp.dest(IMAGE_DECODERS_LEGACY_DIR)
|
2020-08-17 21:30:09 +09:00
|
|
|
);
|
|
|
|
})
|
|
|
|
);
|
|
|
|
|
2020-05-10 20:41:42 +09:00
|
|
|
function buildMinified(defines, dir) {
|
|
|
|
rimraf.sync(dir);
|
|
|
|
|
|
|
|
return merge([
|
|
|
|
createMainBundle(defines).pipe(gulp.dest(dir + "build")),
|
|
|
|
createWorkerBundle(defines).pipe(gulp.dest(dir + "build")),
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
createSandboxBundle(defines).pipe(gulp.dest(dir + "build")),
|
2023-10-18 20:32:50 +09:00
|
|
|
createImageDecodersBundle({ ...defines, IMAGE_DECODERS: true }).pipe(
|
|
|
|
gulp.dest(dir + "image_decoders")
|
|
|
|
),
|
2020-05-10 20:41:42 +09:00
|
|
|
]);
|
|
|
|
}
|
|
|
|
|
2020-10-07 21:28:17 +09:00
|
|
|
async function parseMinified(dir) {
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
const pdfFile = fs.readFileSync(dir + "build/pdf.mjs").toString();
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const pdfWorkerFile = fs
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.readFileSync(dir + "build/pdf.worker.mjs")
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
.toString();
|
|
|
|
const pdfSandboxFile = fs
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.readFileSync(dir + "build/pdf.sandbox.mjs")
|
2020-11-09 22:45:02 +09:00
|
|
|
.toString();
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const pdfImageDecodersFile = fs
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.readFileSync(dir + "image_decoders/pdf.image_decoders.mjs")
|
2020-05-10 20:41:42 +09:00
|
|
|
.toString();
|
2017-04-19 04:00:53 +09:00
|
|
|
|
2020-05-10 20:41:42 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Minifying js files");
|
|
|
|
|
2023-07-08 17:01:16 +09:00
|
|
|
const { minify } = await import("terser");
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const options = {
|
2020-08-13 16:49:46 +09:00
|
|
|
compress: {
|
|
|
|
// V8 chokes on very long sequences, work around that.
|
|
|
|
sequences: false,
|
|
|
|
},
|
|
|
|
keep_classnames: true,
|
|
|
|
keep_fnames: true,
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
module: true,
|
2020-08-13 16:49:46 +09:00
|
|
|
};
|
2020-05-10 20:41:42 +09:00
|
|
|
|
2020-08-13 16:49:46 +09:00
|
|
|
fs.writeFileSync(
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
dir + "build/pdf.min.mjs",
|
2023-07-08 17:01:16 +09:00
|
|
|
(await minify(pdfFile, options)).code
|
2020-08-13 16:49:46 +09:00
|
|
|
);
|
2020-05-10 20:41:42 +09:00
|
|
|
fs.writeFileSync(
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
dir + "build/pdf.worker.min.mjs",
|
2023-07-08 17:01:16 +09:00
|
|
|
(await minify(pdfWorkerFile, options)).code
|
2020-05-10 20:41:42 +09:00
|
|
|
);
|
2020-11-09 22:45:02 +09:00
|
|
|
fs.writeFileSync(
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
dir + "build/pdf.sandbox.min.mjs",
|
2023-07-08 17:01:16 +09:00
|
|
|
(await minify(pdfSandboxFile, options)).code
|
2020-11-09 22:45:02 +09:00
|
|
|
);
|
2020-05-10 20:41:42 +09:00
|
|
|
fs.writeFileSync(
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
dir + "image_decoders/pdf.image_decoders.min.mjs",
|
2023-07-08 17:01:16 +09:00
|
|
|
(await minify(pdfImageDecodersFile, options)).code
|
2020-05-10 20:41:42 +09:00
|
|
|
);
|
|
|
|
|
|
|
|
console.log();
|
|
|
|
console.log("### Cleaning js files");
|
|
|
|
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
fs.unlinkSync(dir + "build/pdf.mjs");
|
|
|
|
fs.unlinkSync(dir + "build/pdf.worker.mjs");
|
|
|
|
fs.unlinkSync(dir + "build/pdf.sandbox.mjs");
|
2020-05-10 20:41:42 +09:00
|
|
|
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
fs.renameSync(dir + "build/pdf.min.mjs", dir + "build/pdf.mjs");
|
|
|
|
fs.renameSync(dir + "build/pdf.worker.min.mjs", dir + "build/pdf.worker.mjs");
|
2020-11-09 22:45:02 +09:00
|
|
|
fs.renameSync(
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
dir + "build/pdf.sandbox.min.mjs",
|
|
|
|
dir + "build/pdf.sandbox.mjs"
|
2020-11-09 22:45:02 +09:00
|
|
|
);
|
2020-05-10 20:41:42 +09:00
|
|
|
fs.renameSync(
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
dir + "image_decoders/pdf.image_decoders.min.mjs",
|
|
|
|
dir + "image_decoders/pdf.image_decoders.mjs"
|
2020-05-10 20:41:42 +09:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
gulp.task(
|
|
|
|
"minified",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(
|
|
|
|
createBuildNumber,
|
|
|
|
"locale",
|
|
|
|
function scriptingMinified() {
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, MINIFIED: true, GENERIC: true };
|
2021-06-04 19:30:09 +09:00
|
|
|
return merge([
|
|
|
|
buildDefaultPreferences(defines, "minified/"),
|
|
|
|
createTemporaryScriptingBundle(defines),
|
|
|
|
]);
|
|
|
|
},
|
2023-07-09 18:37:00 +09:00
|
|
|
async function prefsMinified() {
|
|
|
|
await parseDefaultPreferences("minified/");
|
|
|
|
},
|
2021-06-04 19:30:09 +09:00
|
|
|
function createMinified() {
|
|
|
|
console.log();
|
|
|
|
console.log("### Creating minified viewer");
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, MINIFIED: true, GENERIC: true };
|
2021-06-04 19:30:09 +09:00
|
|
|
|
|
|
|
return buildMinified(defines, MINIFIED_DIR);
|
|
|
|
},
|
|
|
|
async function compressMinified(done) {
|
|
|
|
await parseMinified(MINIFIED_DIR);
|
|
|
|
done();
|
|
|
|
}
|
|
|
|
)
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
2017-02-07 23:53:33 +09:00
|
|
|
|
2020-05-10 20:41:42 +09:00
|
|
|
gulp.task(
|
2021-02-10 02:28:48 +09:00
|
|
|
"minified-legacy",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(
|
|
|
|
createBuildNumber,
|
|
|
|
"locale",
|
|
|
|
function scriptingMinifiedLegacy() {
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = {
|
|
|
|
...DEFINES,
|
2021-06-04 19:30:09 +09:00
|
|
|
MINIFIED: true,
|
|
|
|
GENERIC: true,
|
|
|
|
SKIP_BABEL: false,
|
2023-10-18 20:32:50 +09:00
|
|
|
};
|
2021-06-04 19:30:09 +09:00
|
|
|
return merge([
|
|
|
|
buildDefaultPreferences(defines, "minified-legacy/"),
|
|
|
|
createTemporaryScriptingBundle(defines),
|
|
|
|
]);
|
|
|
|
},
|
2023-07-09 18:37:00 +09:00
|
|
|
async function prefsMinifiedLegacy() {
|
|
|
|
await parseDefaultPreferences("minified-legacy/");
|
|
|
|
},
|
2021-06-04 19:30:09 +09:00
|
|
|
function createMinifiedLegacy() {
|
|
|
|
console.log();
|
|
|
|
console.log("### Creating minified (legacy) viewer");
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = {
|
|
|
|
...DEFINES,
|
2021-06-04 19:30:09 +09:00
|
|
|
MINIFIED: true,
|
|
|
|
GENERIC: true,
|
|
|
|
SKIP_BABEL: false,
|
2023-10-18 20:32:50 +09:00
|
|
|
};
|
2021-06-04 19:30:09 +09:00
|
|
|
|
|
|
|
return buildMinified(defines, MINIFIED_LEGACY_DIR);
|
|
|
|
},
|
|
|
|
async function compressMinifiedLegacy(done) {
|
|
|
|
await parseMinified(MINIFIED_LEGACY_DIR);
|
|
|
|
done();
|
|
|
|
}
|
|
|
|
)
|
2020-05-10 20:41:42 +09:00
|
|
|
);
|
2017-04-19 04:00:53 +09:00
|
|
|
|
2018-03-17 00:46:57 +09:00
|
|
|
function preprocessDefaultPreferences(content) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const licenseHeader = fs.readFileSync("./src/license_header.js").toString();
|
2018-03-17 00:46:57 +09:00
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const MODIFICATION_WARNING =
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
"//\n// THIS FILE IS GENERATED AUTOMATICALLY, DO NOT EDIT MANUALLY!\n//\n";
|
2018-03-17 00:46:57 +09:00
|
|
|
|
2023-10-18 20:32:50 +09:00
|
|
|
const bundleDefines = {
|
|
|
|
...DEFINES,
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
DEFAULT_PREFERENCES: getDefaultPreferences("mozcentral/"),
|
2023-10-18 20:32:50 +09:00
|
|
|
};
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
|
2023-07-08 23:07:54 +09:00
|
|
|
content = preprocessPDFJSCode(
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
{
|
|
|
|
rootPath: __dirname,
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
defines: bundleDefines,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
},
|
|
|
|
content
|
|
|
|
);
|
|
|
|
|
2023-03-30 22:37:28 +09:00
|
|
|
return licenseHeader + "\n" + MODIFICATION_WARNING + "\n" + content + "\n";
|
2018-03-17 00:46:57 +09:00
|
|
|
}
|
|
|
|
|
2023-04-09 19:38:49 +09:00
|
|
|
function replaceMozcentralCSS() {
|
|
|
|
return replace(/var\(--(inline-(?:start|end))\)/g, "$1");
|
|
|
|
}
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
2021-06-04 19:30:09 +09:00
|
|
|
"mozcentral",
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
gulp.series(
|
2021-06-04 19:30:09 +09:00
|
|
|
createBuildNumber,
|
2021-06-03 22:44:17 +09:00
|
|
|
function scriptingMozcentral() {
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, MOZCENTRAL: true };
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
return buildDefaultPreferences(defines, "mozcentral/");
|
|
|
|
},
|
2023-07-09 18:37:00 +09:00
|
|
|
async function prefsMozcentral() {
|
|
|
|
await parseDefaultPreferences("mozcentral/");
|
|
|
|
},
|
2021-06-03 22:44:17 +09:00
|
|
|
function createMozcentral() {
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Building mozilla-central extension");
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, MOZCENTRAL: true };
|
|
|
|
const gvDefines = { ...defines, GECKOVIEW: true };
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
|
|
|
|
const MOZCENTRAL_DIR = BUILD_DIR + "mozcentral/",
|
|
|
|
MOZCENTRAL_EXTENSION_DIR = MOZCENTRAL_DIR + "browser/extensions/pdfjs/",
|
|
|
|
MOZCENTRAL_CONTENT_DIR = MOZCENTRAL_EXTENSION_DIR + "content/",
|
|
|
|
MOZCENTRAL_L10N_DIR =
|
|
|
|
MOZCENTRAL_DIR + "browser/locales/en-US/pdfviewer/",
|
|
|
|
FIREFOX_CONTENT_DIR = EXTENSION_SRC_DIR + "/firefox/content/";
|
|
|
|
|
2022-04-25 17:06:47 +09:00
|
|
|
const MOZCENTRAL_WEB_FILES = [
|
|
|
|
...COMMON_WEB_FILES,
|
|
|
|
"!web/images/toolbarButton-openFile.svg",
|
|
|
|
];
|
2023-04-03 20:23:26 +09:00
|
|
|
const MOZCENTRAL_AUTOPREFIXER_CONFIG = {
|
|
|
|
overrideBrowserslist: ["last 1 firefox versions"],
|
|
|
|
};
|
2022-04-25 17:06:47 +09:00
|
|
|
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
// Clear out everything in the firefox extension build directory
|
|
|
|
rimraf.sync(MOZCENTRAL_DIR);
|
|
|
|
|
|
|
|
return merge([
|
|
|
|
createMainBundle(defines).pipe(
|
|
|
|
gulp.dest(MOZCENTRAL_CONTENT_DIR + "build")
|
|
|
|
),
|
|
|
|
createScriptingBundle(defines).pipe(
|
|
|
|
gulp.dest(MOZCENTRAL_CONTENT_DIR + "build")
|
|
|
|
),
|
|
|
|
createSandboxExternal(defines).pipe(
|
|
|
|
gulp.dest(MOZCENTRAL_CONTENT_DIR + "build")
|
|
|
|
),
|
|
|
|
createWorkerBundle(defines).pipe(
|
|
|
|
gulp.dest(MOZCENTRAL_CONTENT_DIR + "build")
|
|
|
|
),
|
|
|
|
createWebBundle(defines, { defaultPreferencesDir: "mozcentral/" }).pipe(
|
|
|
|
gulp.dest(MOZCENTRAL_CONTENT_DIR + "web")
|
|
|
|
),
|
2023-10-18 20:32:50 +09:00
|
|
|
createGVWebBundle(gvDefines, {
|
2022-12-15 00:40:25 +09:00
|
|
|
defaultPreferencesDir: "mozcentral/",
|
|
|
|
}).pipe(gulp.dest(MOZCENTRAL_CONTENT_DIR + "web")),
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
gulp
|
2022-04-25 17:06:47 +09:00
|
|
|
.src(MOZCENTRAL_WEB_FILES, { base: "web/" })
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
.pipe(gulp.dest(MOZCENTRAL_CONTENT_DIR + "web")),
|
2021-06-10 06:50:50 +09:00
|
|
|
createCMapBundle().pipe(
|
|
|
|
gulp.dest(MOZCENTRAL_CONTENT_DIR + "web/cmaps")
|
|
|
|
),
|
|
|
|
createStandardFontBundle().pipe(
|
|
|
|
gulp.dest(MOZCENTRAL_CONTENT_DIR + "web/standard_fonts")
|
|
|
|
),
|
|
|
|
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
preprocessHTML("web/viewer.html", defines).pipe(
|
|
|
|
gulp.dest(MOZCENTRAL_CONTENT_DIR + "web")
|
|
|
|
),
|
2023-09-21 22:18:12 +09:00
|
|
|
preprocessHTML("web/viewer-geckoview.html", gvDefines).pipe(
|
2022-12-15 00:40:25 +09:00
|
|
|
gulp.dest(MOZCENTRAL_CONTENT_DIR + "web")
|
|
|
|
),
|
|
|
|
|
2022-03-15 21:53:49 +09:00
|
|
|
preprocessCSS("web/viewer.css", defines)
|
2023-09-23 01:27:08 +09:00
|
|
|
.pipe(
|
|
|
|
postcss([
|
|
|
|
discardCommentsCSS(),
|
|
|
|
autoprefixer(MOZCENTRAL_AUTOPREFIXER_CONFIG),
|
|
|
|
])
|
|
|
|
)
|
2023-04-09 19:38:49 +09:00
|
|
|
.pipe(replaceMozcentralCSS())
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
.pipe(gulp.dest(MOZCENTRAL_CONTENT_DIR + "web")),
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
2023-09-21 22:18:12 +09:00
|
|
|
preprocessCSS("web/viewer-geckoview.css", gvDefines)
|
2023-09-23 01:27:08 +09:00
|
|
|
.pipe(
|
|
|
|
postcss([
|
|
|
|
discardCommentsCSS(),
|
|
|
|
autoprefixer(MOZCENTRAL_AUTOPREFIXER_CONFIG),
|
|
|
|
])
|
|
|
|
)
|
2023-04-09 19:38:49 +09:00
|
|
|
.pipe(replaceMozcentralCSS())
|
2022-12-15 00:40:25 +09:00
|
|
|
.pipe(gulp.dest(MOZCENTRAL_CONTENT_DIR + "web")),
|
|
|
|
|
2023-10-13 23:23:17 +09:00
|
|
|
gulp.src("l10n/en-US/*.ftl").pipe(gulp.dest(MOZCENTRAL_L10N_DIR)),
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
gulp.src("LICENSE").pipe(gulp.dest(MOZCENTRAL_EXTENSION_DIR)),
|
|
|
|
gulp
|
2023-03-27 18:40:58 +09:00
|
|
|
.src(FIREFOX_CONTENT_DIR + "PdfJsDefaultPreferences.sys.mjs")
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
.pipe(transform("utf8", preprocessDefaultPreferences))
|
|
|
|
.pipe(gulp.dest(MOZCENTRAL_CONTENT_DIR)),
|
|
|
|
]);
|
|
|
|
}
|
|
|
|
)
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
2017-02-07 23:53:33 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
2021-06-04 19:30:09 +09:00
|
|
|
"chromium",
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
gulp.series(
|
2021-06-04 19:30:09 +09:00
|
|
|
createBuildNumber,
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
"locale",
|
2021-06-03 22:44:17 +09:00
|
|
|
function scriptingChromium() {
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, CHROME: true, SKIP_BABEL: false };
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
return merge([
|
|
|
|
buildDefaultPreferences(defines, "chromium/"),
|
|
|
|
createTemporaryScriptingBundle(defines),
|
|
|
|
]);
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
},
|
2023-07-09 18:37:00 +09:00
|
|
|
async function prefsChromium() {
|
|
|
|
await parseDefaultPreferences("chromium/");
|
|
|
|
},
|
2021-06-03 22:44:17 +09:00
|
|
|
function createChromium() {
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Building Chromium extension");
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, CHROME: true, SKIP_BABEL: false };
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const CHROME_BUILD_DIR = BUILD_DIR + "/chromium/",
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
CHROME_BUILD_CONTENT_DIR = CHROME_BUILD_DIR + "/content/";
|
|
|
|
|
2022-05-08 05:05:39 +09:00
|
|
|
const CHROME_WEB_FILES = [
|
|
|
|
...COMMON_WEB_FILES,
|
|
|
|
"!web/images/toolbarButton-openFile.svg",
|
|
|
|
];
|
|
|
|
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
// Clear out everything in the chrome extension build directory
|
|
|
|
rimraf.sync(CHROME_BUILD_DIR);
|
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const version = getVersionJSON().version;
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
|
|
|
|
return merge([
|
|
|
|
createMainBundle(defines).pipe(
|
|
|
|
gulp.dest(CHROME_BUILD_CONTENT_DIR + "build")
|
|
|
|
),
|
|
|
|
createWorkerBundle(defines).pipe(
|
|
|
|
gulp.dest(CHROME_BUILD_CONTENT_DIR + "build")
|
|
|
|
),
|
|
|
|
createSandboxBundle(defines).pipe(
|
|
|
|
gulp.dest(CHROME_BUILD_CONTENT_DIR + "build")
|
|
|
|
),
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
createWebBundle(defines, { defaultPreferencesDir: "chromium/" }).pipe(
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
gulp.dest(CHROME_BUILD_CONTENT_DIR + "web")
|
|
|
|
),
|
|
|
|
gulp
|
2022-05-08 05:05:39 +09:00
|
|
|
.src(CHROME_WEB_FILES, { base: "web/" })
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
.pipe(gulp.dest(CHROME_BUILD_CONTENT_DIR + "web")),
|
|
|
|
|
|
|
|
gulp
|
2023-10-13 23:23:17 +09:00
|
|
|
.src(["web/locale/*/viewer.ftl", "web/locale/locale.json"], {
|
|
|
|
base: "web/",
|
|
|
|
})
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
.pipe(gulp.dest(CHROME_BUILD_CONTENT_DIR + "web")),
|
2021-06-10 06:50:50 +09:00
|
|
|
createCMapBundle().pipe(
|
|
|
|
gulp.dest(CHROME_BUILD_CONTENT_DIR + "web/cmaps")
|
|
|
|
),
|
|
|
|
createStandardFontBundle().pipe(
|
|
|
|
gulp.dest(CHROME_BUILD_CONTENT_DIR + "web/standard_fonts")
|
|
|
|
),
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
|
|
|
|
preprocessHTML("web/viewer.html", defines).pipe(
|
|
|
|
gulp.dest(CHROME_BUILD_CONTENT_DIR + "web")
|
|
|
|
),
|
2022-03-15 21:53:49 +09:00
|
|
|
preprocessCSS("web/viewer.css", defines)
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
.pipe(
|
2022-03-14 02:30:51 +09:00
|
|
|
postcss([
|
|
|
|
postcssDirPseudoClass(),
|
2023-09-23 01:27:08 +09:00
|
|
|
discardCommentsCSS(),
|
2023-08-05 01:21:27 +09:00
|
|
|
postcssNesting(),
|
2023-04-03 20:23:26 +09:00
|
|
|
autoprefixer(AUTOPREFIXER_CONFIG),
|
2022-03-14 02:30:51 +09:00
|
|
|
])
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
)
|
|
|
|
.pipe(gulp.dest(CHROME_BUILD_CONTENT_DIR + "web")),
|
|
|
|
|
|
|
|
gulp.src("LICENSE").pipe(gulp.dest(CHROME_BUILD_DIR)),
|
|
|
|
gulp
|
|
|
|
.src("extensions/chromium/manifest.json")
|
|
|
|
.pipe(replace(/\bPDFJSSCRIPT_VERSION\b/g, version))
|
|
|
|
.pipe(gulp.dest(CHROME_BUILD_DIR)),
|
|
|
|
gulp
|
|
|
|
.src(
|
|
|
|
[
|
|
|
|
"extensions/chromium/**/*.{html,js,css,png}",
|
|
|
|
"extensions/chromium/preferences_schema.json",
|
|
|
|
],
|
|
|
|
{ base: "extensions/chromium/" }
|
|
|
|
)
|
|
|
|
.pipe(gulp.dest(CHROME_BUILD_DIR)),
|
|
|
|
]);
|
|
|
|
}
|
|
|
|
)
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
2016-04-23 07:20:47 +09:00
|
|
|
|
2023-03-07 03:47:18 +09:00
|
|
|
gulp.task("jsdoc", function (done) {
|
2016-10-16 23:06:37 +09:00
|
|
|
console.log();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log("### Generating documentation (JSDoc)");
|
2016-10-16 23:06:37 +09:00
|
|
|
|
2022-02-27 07:38:11 +09:00
|
|
|
const JSDOC_FILES = ["src/display/api.js"];
|
2016-10-16 23:06:37 +09:00
|
|
|
|
2023-03-07 03:47:18 +09:00
|
|
|
rimraf(JSDOC_BUILD_DIR, function () {
|
|
|
|
mkdirp(JSDOC_BUILD_DIR).then(function () {
|
|
|
|
const command =
|
|
|
|
'"node_modules/.bin/jsdoc" -d ' +
|
|
|
|
JSDOC_BUILD_DIR +
|
|
|
|
" " +
|
|
|
|
JSDOC_FILES.join(" ");
|
|
|
|
exec(command, done);
|
|
|
|
});
|
|
|
|
});
|
2016-10-16 23:06:37 +09:00
|
|
|
});
|
|
|
|
|
2020-07-23 05:38:04 +09:00
|
|
|
gulp.task("types", function (done) {
|
2020-08-03 02:06:50 +09:00
|
|
|
console.log("### Generating TypeScript definitions using `tsc`");
|
2021-06-19 23:24:34 +09:00
|
|
|
exec(
|
2023-08-31 19:41:25 +09:00
|
|
|
`"node_modules/.bin/tsc" --outDir ${TYPES_DIR} --project .`,
|
2023-08-31 19:59:27 +09:00
|
|
|
function () {
|
|
|
|
exec(`"node_modules/.bin/tsc-alias" --outDir ${TYPES_DIR}`, done);
|
|
|
|
}
|
2021-06-19 23:24:34 +09:00
|
|
|
);
|
2020-07-23 05:38:04 +09:00
|
|
|
});
|
|
|
|
|
2021-03-20 21:06:38 +09:00
|
|
|
function buildLibHelper(bundleDefines, inputStream, outputDir) {
|
2023-10-13 19:11:29 +09:00
|
|
|
function babelPluginReplaceNonWebpackImport(b) {
|
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 20:31:33 +09:00
|
|
|
return {
|
|
|
|
visitor: {
|
|
|
|
Identifier(curPath, state) {
|
2023-10-13 19:11:29 +09:00
|
|
|
if (curPath.node.name === "__non_webpack_import__") {
|
2023-07-13 19:20:58 +09:00
|
|
|
curPath.replaceWith(b.types.identifier("import"));
|
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 20:31:33 +09:00
|
|
|
}
|
|
|
|
},
|
|
|
|
},
|
|
|
|
};
|
|
|
|
}
|
2023-10-18 20:32:50 +09:00
|
|
|
function preprocessLib(content) {
|
2023-08-13 15:55:58 +09:00
|
|
|
const skipBabel = bundleDefines.SKIP_BABEL;
|
2023-07-08 23:07:54 +09:00
|
|
|
content = preprocessPDFJSCode(ctx, content);
|
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 20:31:33 +09:00
|
|
|
content = babel.transform(content, {
|
|
|
|
sourceType: "module",
|
2023-10-13 19:11:29 +09:00
|
|
|
presets: skipBabel
|
|
|
|
? undefined
|
|
|
|
: [["@babel/preset-env", { loose: false, modules: false }]],
|
|
|
|
plugins: [babelPluginReplaceNonWebpackImport],
|
2022-08-19 17:45:40 +09:00
|
|
|
targets: BABEL_TARGETS,
|
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 20:31:33 +09:00
|
|
|
}).code;
|
2023-03-23 20:34:08 +09:00
|
|
|
content = content.replaceAll(
|
2023-10-13 19:11:29 +09:00
|
|
|
/(\sfrom\s".*?)(?:\/src)(\/[^"]*"?;)$/gm,
|
|
|
|
(all, prefix, suffix) => prefix + suffix
|
2023-03-23 20:34:08 +09:00
|
|
|
);
|
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 20:31:33 +09:00
|
|
|
return licenseHeaderLibre + content;
|
|
|
|
}
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const ctx = {
|
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 20:31:33 +09:00
|
|
|
rootPath: __dirname,
|
|
|
|
saveComments: false,
|
|
|
|
defines: bundleDefines,
|
|
|
|
map: {
|
2023-10-13 19:11:29 +09:00
|
|
|
"pdfjs-lib": "../pdf.js",
|
|
|
|
"display-fetch_stream": "./fetch_stream.js",
|
|
|
|
"display-l10n_utils": "../web/l10n_utils.js",
|
|
|
|
"display-network": "./network.js",
|
|
|
|
"display-node_stream": "./node_stream.js",
|
|
|
|
"display-node_utils": "./node_utils.js",
|
2023-10-13 23:23:17 +09:00
|
|
|
"fluent-bundle": "../../../node_modules/@fluent/bundle/esm/index.js",
|
|
|
|
"fluent-dom": "../../../node_modules/@fluent/dom/esm/index.js",
|
2023-10-19 03:13:10 +09:00
|
|
|
"web-l10n_utils": "../web/l10n_utils.js",
|
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 20:31:33 +09:00
|
|
|
},
|
|
|
|
};
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const licenseHeaderLibre = fs
|
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 20:31:33 +09:00
|
|
|
.readFileSync("./src/license_header_libre.js")
|
|
|
|
.toString();
|
2021-03-20 21:06:38 +09:00
|
|
|
return inputStream
|
2023-10-18 20:32:50 +09:00
|
|
|
.pipe(transform("utf8", preprocessLib))
|
2021-03-20 21:06:38 +09:00
|
|
|
.pipe(gulp.dest(outputDir));
|
|
|
|
}
|
|
|
|
|
|
|
|
function buildLib(defines, dir) {
|
|
|
|
const versionInfo = getVersionJSON();
|
|
|
|
|
2023-10-18 20:32:50 +09:00
|
|
|
const bundleDefines = {
|
|
|
|
...defines,
|
2021-03-20 21:06:38 +09:00
|
|
|
BUNDLE_VERSION: versionInfo.version,
|
|
|
|
BUNDLE_BUILD: versionInfo.commit,
|
2023-06-25 23:02:31 +09:00
|
|
|
TESTING: defines.TESTING ?? process.env.TESTING === "true",
|
2021-03-20 21:06:38 +09:00
|
|
|
DEFAULT_PREFERENCES: getDefaultPreferences(
|
|
|
|
defines.SKIP_BABEL ? "lib/" : "lib-legacy/"
|
|
|
|
),
|
2023-10-18 20:32:50 +09:00
|
|
|
};
|
2021-03-20 21:06:38 +09:00
|
|
|
|
|
|
|
const inputStream = merge([
|
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 20:31:33 +09:00
|
|
|
gulp.src(
|
|
|
|
[
|
2021-02-01 21:44:03 +09:00
|
|
|
"src/{core,display,shared}/**/*.js",
|
2023-07-07 19:36:21 +09:00
|
|
|
"src/{pdf,pdf.image_decoders,pdf.worker}.js",
|
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 20:31:33 +09:00
|
|
|
],
|
|
|
|
{ base: "src/" }
|
|
|
|
),
|
2023-10-13 23:23:17 +09:00
|
|
|
gulp.src(["web/*.js", "!web/{pdfjs,viewer}.js"], { base: "." }),
|
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 20:31:33 +09:00
|
|
|
gulp.src("test/unit/*.js", { base: "." }),
|
2021-03-20 21:06:38 +09:00
|
|
|
]);
|
|
|
|
|
|
|
|
return buildLibHelper(bundleDefines, inputStream, dir);
|
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 20:31:33 +09:00
|
|
|
}
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"lib",
|
2020-11-09 22:45:02 +09:00
|
|
|
gulp.series(
|
2021-06-04 19:30:09 +09:00
|
|
|
createBuildNumber,
|
2021-06-03 22:44:17 +09:00
|
|
|
function scriptingLib() {
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, GENERIC: true, LIB: true };
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
return merge([
|
|
|
|
buildDefaultPreferences(defines, "lib/"),
|
|
|
|
createTemporaryScriptingBundle(defines),
|
|
|
|
]);
|
2020-11-09 22:45:02 +09:00
|
|
|
},
|
2023-07-09 18:37:00 +09:00
|
|
|
async function prefsLib() {
|
|
|
|
await parseDefaultPreferences("lib/");
|
|
|
|
},
|
2021-06-03 22:44:17 +09:00
|
|
|
function createLib() {
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, GENERIC: true, LIB: true };
|
2020-11-09 22:45:02 +09:00
|
|
|
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
return merge([
|
|
|
|
buildLib(defines, "build/lib/"),
|
|
|
|
createSandboxBundle(defines).pipe(gulp.dest("build/lib/")),
|
|
|
|
]);
|
2020-11-09 22:45:02 +09:00
|
|
|
}
|
|
|
|
)
|
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 20:31:33 +09:00
|
|
|
);
|
|
|
|
|
|
|
|
gulp.task(
|
2021-02-10 02:28:48 +09:00
|
|
|
"lib-legacy",
|
2020-11-09 22:45:02 +09:00
|
|
|
gulp.series(
|
2021-06-04 19:30:09 +09:00
|
|
|
createBuildNumber,
|
2021-06-03 22:44:17 +09:00
|
|
|
function scriptingLibLegacy() {
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = {
|
|
|
|
...DEFINES,
|
2020-11-09 22:45:02 +09:00
|
|
|
GENERIC: true,
|
|
|
|
LIB: true,
|
|
|
|
SKIP_BABEL: false,
|
2023-10-18 20:32:50 +09:00
|
|
|
};
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
return merge([
|
|
|
|
buildDefaultPreferences(defines, "lib-legacy/"),
|
|
|
|
createTemporaryScriptingBundle(defines),
|
|
|
|
]);
|
2020-11-09 22:45:02 +09:00
|
|
|
},
|
2023-07-09 18:37:00 +09:00
|
|
|
async function prefsLibLegacy() {
|
|
|
|
await parseDefaultPreferences("lib-legacy/");
|
|
|
|
},
|
2021-06-03 22:44:17 +09:00
|
|
|
function createLibLegacy() {
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = {
|
|
|
|
...DEFINES,
|
2020-11-09 22:45:02 +09:00
|
|
|
GENERIC: true,
|
|
|
|
LIB: true,
|
|
|
|
SKIP_BABEL: false,
|
2023-10-18 20:32:50 +09:00
|
|
|
};
|
2020-11-09 22:45:02 +09:00
|
|
|
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
return merge([
|
2021-02-10 02:28:48 +09:00
|
|
|
buildLib(defines, "build/lib-legacy/"),
|
|
|
|
createSandboxBundle(defines).pipe(gulp.dest("build/lib-legacy/")),
|
Re-factor how the `pdf.sandbox.js` file is built (PR 12604 follow-up)
The way that the `pdf.sandbox.js` building was implemented feels all kinds of inconsistent/wrong, and it "sticks out" quite a bit when compared to the rest of the `gulpfile.js`. This patch thus attempts to improve the current situation slightly, to hopefully make future maintenance easier.
One thing that strikes you, pretty immediately, when looking at PR 12604 is that the two new `gulp`-tasks added (i.e. `sandbox` and `watch-sandbox`) don't even work!?
The reason for this is that they implicitly dependent upon the result of the `buildnumber`-task, which isn't listed as a dependency. (Try running `gulp clean` *first*, and invoking any of the new `gulp`-tasks will inevitably fail.)
Furthermore, there's another (potentially big) problem with the implementation of e.g. the `gulp sandbox` task, since it doesn't actually wait for all building to complete before the task is considered as "done". This has the potential to cause all sorts of subtle bugs elsewhere, and the fact that things even "work" as-is can probably be attributed mostly to luck.
Unfortunately there's no *perfect* way to improve things here, since the `pdf.sandbox.js` file depends on including the `pdf.scripting.js` file as a string, however I firmly believe that improvements are still possible here.
To that end, this patch updates all relevant build-targets to create a *temporary* `pdf.scripting.js` file as part of the setup in the `gulp`-tasks, and then reads that file during the `pdf.sandbox.js` building.
This at least allows us to bring all of this "sandbox"-build code much more in-line with the existing build-system.
2020-12-05 21:59:46 +09:00
|
|
|
]);
|
2020-11-09 22:45:02 +09:00
|
|
|
}
|
|
|
|
)
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
|
|
|
|
2019-10-15 04:19:31 +09:00
|
|
|
function compressPublish(targetName, dir) {
|
|
|
|
return gulp
|
|
|
|
.src(dir + "**")
|
|
|
|
.pipe(zip(targetName))
|
|
|
|
.pipe(gulp.dest(BUILD_DIR))
|
2020-04-14 19:28:14 +09:00
|
|
|
.on("end", function () {
|
2019-10-15 04:19:31 +09:00
|
|
|
console.log("Built distribution file: " + targetName);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"publish",
|
2021-06-03 22:44:17 +09:00
|
|
|
gulp.series("generic", "generic-legacy", function createPublish(done) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const version = JSON.parse(
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
fs.readFileSync(BUILD_DIR + "version.json").toString()
|
|
|
|
).version;
|
|
|
|
|
2022-01-02 22:28:53 +09:00
|
|
|
config.stableVersion = version;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
2019-10-15 04:19:31 +09:00
|
|
|
return merge([
|
|
|
|
createStringSource(CONFIG_FILE, JSON.stringify(config, null, 2)).pipe(
|
|
|
|
gulp.dest(".")
|
|
|
|
),
|
|
|
|
compressPublish("pdfjs-" + version + "-dist.zip", GENERIC_DIR),
|
2021-02-10 02:28:48 +09:00
|
|
|
compressPublish(
|
|
|
|
"pdfjs-" + version + "-legacy-dist.zip",
|
|
|
|
GENERIC_LEGACY_DIR
|
|
|
|
),
|
2019-10-15 04:19:31 +09:00
|
|
|
]);
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
})
|
|
|
|
);
|
2016-04-27 06:28:36 +09:00
|
|
|
|
2021-06-04 19:30:09 +09:00
|
|
|
function setTestEnv(done) {
|
2020-04-17 19:06:27 +09:00
|
|
|
process.env.TESTING = "true";
|
2020-12-11 20:11:01 +09:00
|
|
|
// TODO: Re-write the relevant unit-tests, which are using `new Date(...)`,
|
|
|
|
// to not required the following time-zone hack since it doesn't work
|
|
|
|
// when the unit-tests are run directly in the browser.
|
|
|
|
process.env.TZ = "UTC";
|
2018-11-19 02:33:23 +09:00
|
|
|
done();
|
2021-06-04 19:30:09 +09:00
|
|
|
}
|
2018-06-12 00:25:50 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"test",
|
2023-02-09 19:16:10 +09:00
|
|
|
gulp.series(setTestEnv, "generic", "components", function runTest() {
|
|
|
|
return streamqueue(
|
|
|
|
{ objectMode: true },
|
|
|
|
createTestSource("unit"),
|
|
|
|
createTestSource("browser"),
|
|
|
|
createTestSource("integration")
|
|
|
|
);
|
|
|
|
})
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
|
|
|
|
|
|
|
gulp.task(
|
|
|
|
"bottest",
|
2023-02-09 19:16:10 +09:00
|
|
|
gulp.series(setTestEnv, "generic", "components", function runBotTest() {
|
|
|
|
return streamqueue(
|
|
|
|
{ objectMode: true },
|
|
|
|
createTestSource("unit", { bot: true }),
|
|
|
|
createTestSource("font", { bot: true }),
|
|
|
|
createTestSource("browser", { bot: true }),
|
|
|
|
createTestSource("integration")
|
|
|
|
);
|
|
|
|
})
|
2021-08-02 23:37:42 +09:00
|
|
|
);
|
|
|
|
|
|
|
|
gulp.task(
|
|
|
|
"xfatest",
|
2023-02-09 19:16:10 +09:00
|
|
|
gulp.series(setTestEnv, "generic", "components", function runXfaTest() {
|
|
|
|
return streamqueue(
|
|
|
|
{ objectMode: true },
|
|
|
|
createTestSource("unit"),
|
|
|
|
createTestSource("browser", { xfaOnly: true }),
|
|
|
|
createTestSource("integration")
|
|
|
|
);
|
|
|
|
})
|
2021-08-02 23:37:42 +09:00
|
|
|
);
|
|
|
|
|
|
|
|
gulp.task(
|
|
|
|
"botxfatest",
|
2023-02-09 19:16:10 +09:00
|
|
|
gulp.series(setTestEnv, "generic", "components", function runBotXfaTest() {
|
|
|
|
return streamqueue(
|
|
|
|
{ objectMode: true },
|
|
|
|
createTestSource("unit", { bot: true }),
|
|
|
|
createTestSource("font", { bot: true }),
|
|
|
|
createTestSource("browser", { bot: true, xfaOnly: true }),
|
|
|
|
createTestSource("integration")
|
|
|
|
);
|
|
|
|
})
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
|
|
|
|
|
|
|
gulp.task(
|
|
|
|
"browsertest",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(setTestEnv, "generic", "components", function runBrowserTest() {
|
|
|
|
return createTestSource("browser");
|
|
|
|
})
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
|
|
|
|
2021-07-14 18:53:07 +09:00
|
|
|
gulp.task(
|
|
|
|
"botbrowsertest",
|
|
|
|
gulp.series(
|
|
|
|
setTestEnv,
|
|
|
|
"generic",
|
|
|
|
"components",
|
|
|
|
function runBotBrowserTest() {
|
|
|
|
return streamqueue(
|
|
|
|
{ objectMode: true },
|
2021-08-02 23:37:42 +09:00
|
|
|
createTestSource("browser", { bot: true })
|
2021-07-14 18:53:07 +09:00
|
|
|
);
|
|
|
|
}
|
|
|
|
)
|
|
|
|
);
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"unittest",
|
2023-02-09 19:16:10 +09:00
|
|
|
gulp.series(setTestEnv, "generic", function runUnitTest() {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return createTestSource("unit");
|
|
|
|
})
|
|
|
|
);
|
|
|
|
|
2020-12-01 02:11:28 +09:00
|
|
|
gulp.task(
|
|
|
|
"integrationtest",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(setTestEnv, "generic", function runIntegrationTest() {
|
2020-12-01 02:11:28 +09:00
|
|
|
return createTestSource("integration");
|
|
|
|
})
|
|
|
|
);
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"fonttest",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(setTestEnv, function runFontTest() {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return createTestSource("font");
|
|
|
|
})
|
|
|
|
);
|
|
|
|
|
|
|
|
gulp.task(
|
|
|
|
"makeref",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(setTestEnv, "generic", "components", function runMakeref(done) {
|
|
|
|
makeRef(done);
|
|
|
|
})
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
|
|
|
|
|
|
|
gulp.task(
|
|
|
|
"botmakeref",
|
2021-06-03 22:44:17 +09:00
|
|
|
gulp.series(
|
2021-06-04 19:30:09 +09:00
|
|
|
setTestEnv,
|
2021-06-03 22:44:17 +09:00
|
|
|
"generic",
|
|
|
|
"components",
|
|
|
|
function runBotMakeref(done) {
|
|
|
|
makeRef(done, true);
|
|
|
|
}
|
|
|
|
)
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
|
|
|
|
2020-08-03 02:06:50 +09:00
|
|
|
gulp.task(
|
|
|
|
"typestest",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(
|
|
|
|
setTestEnv,
|
|
|
|
"generic",
|
|
|
|
"types",
|
|
|
|
function createTypesTest() {
|
|
|
|
return merge([
|
2022-09-03 20:05:59 +09:00
|
|
|
packageJson().pipe(gulp.dest(TYPESTEST_DIR)),
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp
|
|
|
|
.src([
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
GENERIC_DIR + "build/pdf.mjs",
|
|
|
|
GENERIC_DIR + "build/pdf.worker.mjs",
|
2021-06-04 19:30:09 +09:00
|
|
|
SRC_DIR + "pdf.worker.entry.js",
|
|
|
|
])
|
|
|
|
.pipe(gulp.dest(TYPESTEST_DIR + "build/")),
|
|
|
|
gulp
|
|
|
|
.src(TYPES_DIR + "**/*", { base: TYPES_DIR })
|
|
|
|
.pipe(gulp.dest(TYPESTEST_DIR + "types/")),
|
|
|
|
]);
|
|
|
|
},
|
|
|
|
function runTypesTest(done) {
|
|
|
|
exec('"node_modules/.bin/tsc" -p test/types', function (err, stdout) {
|
|
|
|
if (err) {
|
|
|
|
console.log(`Couldn't compile TypeScript test: ${stdout}`);
|
|
|
|
}
|
|
|
|
done(err);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
)
|
2020-07-23 05:38:04 +09:00
|
|
|
);
|
|
|
|
|
2021-06-04 19:30:09 +09:00
|
|
|
function createBaseline(done) {
|
2017-02-22 07:24:07 +09:00
|
|
|
console.log();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log("### Creating baseline environment");
|
2017-02-22 07:24:07 +09:00
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const baselineCommit = process.env.BASELINE;
|
2017-02-22 07:24:07 +09:00
|
|
|
if (!baselineCommit) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
done(new Error("Missing baseline commit. Specify the BASELINE variable."));
|
2017-02-22 07:24:07 +09:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
let initializeCommand = "git fetch origin";
|
2017-02-22 07:24:07 +09:00
|
|
|
if (!checkDir(BASELINE_DIR)) {
|
|
|
|
mkdirp.sync(BASELINE_DIR);
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
initializeCommand = "git clone ../../ .";
|
2017-02-22 07:24:07 +09:00
|
|
|
}
|
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const workingDirectory = path.resolve(process.cwd(), BASELINE_DIR);
|
2020-04-14 19:28:14 +09:00
|
|
|
exec(initializeCommand, { cwd: workingDirectory }, function (error) {
|
2017-02-22 07:24:07 +09:00
|
|
|
if (error) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
done(new Error("Baseline clone/fetch failed."));
|
2017-02-22 07:24:07 +09:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-11-29 17:59:03 +09:00
|
|
|
exec(
|
|
|
|
"git checkout " + baselineCommit,
|
|
|
|
{ cwd: workingDirectory },
|
|
|
|
function (error2) {
|
|
|
|
if (error2) {
|
|
|
|
done(new Error("Baseline commit checkout failed."));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
console.log('Baseline commit "' + baselineCommit + '" checked out.');
|
|
|
|
done();
|
2017-02-22 07:24:07 +09:00
|
|
|
}
|
2020-11-29 17:59:03 +09:00
|
|
|
);
|
2017-02-22 07:24:07 +09:00
|
|
|
});
|
2021-06-04 19:30:09 +09:00
|
|
|
}
|
2017-02-22 07:24:07 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"unittestcli",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(setTestEnv, "lib-legacy", function runUnitTestCli(done) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const options = [
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
"node_modules/jasmine/bin/jasmine",
|
|
|
|
"JASMINE_CONFIG_PATH=test/unit/clitests.json",
|
|
|
|
];
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const jasmineProcess = startNode(options, { stdio: "inherit" });
|
2020-04-14 19:28:14 +09:00
|
|
|
jasmineProcess.on("close", function (code) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
if (code !== 0) {
|
|
|
|
done(new Error("Unit tests failed."));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
done();
|
|
|
|
});
|
|
|
|
})
|
|
|
|
);
|
2016-05-02 23:58:29 +09:00
|
|
|
|
2020-04-14 19:28:14 +09:00
|
|
|
gulp.task("lint", function (done) {
|
2020-02-16 18:42:07 +09:00
|
|
|
console.log();
|
2020-08-29 23:35:27 +09:00
|
|
|
console.log("### Linting JS/CSS files");
|
2020-02-16 18:42:07 +09:00
|
|
|
|
|
|
|
// Ensure that we lint the Firefox specific *.jsm files too.
|
2020-08-29 23:35:27 +09:00
|
|
|
const esLintOptions = [
|
2020-02-16 18:42:07 +09:00
|
|
|
"node_modules/eslint/bin/eslint",
|
|
|
|
"--ext",
|
2023-07-08 16:29:51 +09:00
|
|
|
".js,.jsm,.mjs,.json",
|
2020-02-16 18:42:07 +09:00
|
|
|
".",
|
|
|
|
"--report-unused-disable-directives",
|
|
|
|
];
|
2020-02-16 23:10:28 +09:00
|
|
|
if (process.argv.includes("--fix")) {
|
2020-08-29 23:35:27 +09:00
|
|
|
esLintOptions.push("--fix");
|
2020-02-16 23:10:28 +09:00
|
|
|
}
|
2020-08-29 23:35:27 +09:00
|
|
|
|
|
|
|
const styleLintOptions = [
|
2023-07-22 18:34:14 +09:00
|
|
|
"node_modules/stylelint/bin/stylelint.mjs",
|
2020-08-29 23:35:27 +09:00
|
|
|
"**/*.css",
|
|
|
|
"--report-needless-disables",
|
|
|
|
];
|
|
|
|
if (process.argv.includes("--fix")) {
|
|
|
|
styleLintOptions.push("--fix");
|
|
|
|
}
|
|
|
|
|
|
|
|
const esLintProcess = startNode(esLintOptions, { stdio: "inherit" });
|
|
|
|
esLintProcess.on("close", function (esLintCode) {
|
|
|
|
if (esLintCode !== 0) {
|
2020-02-16 18:42:07 +09:00
|
|
|
done(new Error("ESLint failed."));
|
|
|
|
return;
|
|
|
|
}
|
2020-08-29 23:35:27 +09:00
|
|
|
|
|
|
|
const styleLintProcess = startNode(styleLintOptions, { stdio: "inherit" });
|
|
|
|
styleLintProcess.on("close", function (styleLintCode) {
|
|
|
|
if (styleLintCode !== 0) {
|
|
|
|
done(new Error("Stylelint failed."));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
console.log("files checked, no errors found");
|
|
|
|
done();
|
|
|
|
});
|
2020-02-16 18:42:07 +09:00
|
|
|
});
|
|
|
|
});
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
2020-02-16 18:42:07 +09:00
|
|
|
"lint-chromium",
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
gulp.series(
|
2021-06-03 22:44:17 +09:00
|
|
|
function scriptingLintChromium() {
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = {
|
|
|
|
...DEFINES,
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
CHROME: true,
|
|
|
|
SKIP_BABEL: false,
|
2021-08-20 02:54:36 +09:00
|
|
|
TESTING: false,
|
2023-10-18 20:32:50 +09:00
|
|
|
};
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
return buildDefaultPreferences(defines, "lint-chromium/");
|
|
|
|
},
|
2023-07-09 18:37:00 +09:00
|
|
|
async function prefsLintChromium() {
|
|
|
|
await parseDefaultPreferences("lint-chromium/");
|
|
|
|
},
|
2021-06-03 22:44:17 +09:00
|
|
|
function runLintChromium(done) {
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Checking supplemental Chromium files");
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
if (
|
|
|
|
!checkChromePreferencesFile(
|
|
|
|
"extensions/chromium/preferences_schema.json",
|
|
|
|
getDefaultPreferences("lint-chromium/")
|
|
|
|
)
|
|
|
|
) {
|
|
|
|
done(new Error("chromium/preferences_schema is not in sync."));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
done();
|
2020-02-16 18:42:07 +09:00
|
|
|
}
|
Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.
With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.
---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-18 22:33:54 +09:00
|
|
|
)
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
|
|
|
|
2020-12-05 23:51:39 +09:00
|
|
|
gulp.task(
|
|
|
|
"dev-sandbox",
|
|
|
|
gulp.series(
|
2021-06-03 22:44:17 +09:00
|
|
|
function scriptingDevSandbox() {
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, GENERIC: true, TESTING: true };
|
2020-12-05 23:51:39 +09:00
|
|
|
return createTemporaryScriptingBundle(defines, {
|
|
|
|
disableVersionInfo: true,
|
|
|
|
});
|
|
|
|
},
|
2021-06-03 22:44:17 +09:00
|
|
|
function createDevSandbox() {
|
2020-12-05 23:51:39 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Building development sandbox");
|
|
|
|
|
2023-10-18 20:32:50 +09:00
|
|
|
const defines = { ...DEFINES, GENERIC: true, TESTING: true };
|
2020-12-05 23:51:39 +09:00
|
|
|
const sandboxDir = BUILD_DIR + "dev-sandbox/";
|
|
|
|
|
|
|
|
rimraf.sync(sandboxDir);
|
2016-03-05 00:36:46 +09:00
|
|
|
|
2020-12-05 23:51:39 +09:00
|
|
|
return createSandboxBundle(defines, {
|
|
|
|
disableVersionInfo: true,
|
|
|
|
}).pipe(gulp.dest(sandboxDir));
|
|
|
|
}
|
|
|
|
)
|
|
|
|
);
|
|
|
|
|
|
|
|
gulp.task(
|
|
|
|
"server",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.parallel(
|
|
|
|
function watchDevSandbox() {
|
|
|
|
gulp.watch(
|
|
|
|
[
|
|
|
|
"src/pdf.{sandbox,sandbox.external,scripting}.js",
|
|
|
|
"src/scripting_api/*.js",
|
|
|
|
"src/shared/scripting_utils.js",
|
|
|
|
"external/quickjs/*.js",
|
|
|
|
],
|
|
|
|
{ ignoreInitial: false },
|
|
|
|
gulp.series("dev-sandbox")
|
|
|
|
);
|
|
|
|
},
|
2023-07-08 19:44:37 +09:00
|
|
|
async function createServer() {
|
2021-06-04 19:30:09 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Starting local server");
|
2020-12-05 23:51:39 +09:00
|
|
|
|
2023-07-08 19:44:37 +09:00
|
|
|
const { WebServer } = await import("./test/webserver.mjs");
|
2021-06-04 19:30:09 +09:00
|
|
|
const server = new WebServer();
|
|
|
|
server.port = 8888;
|
|
|
|
server.start();
|
|
|
|
}
|
|
|
|
)
|
2020-12-05 23:51:39 +09:00
|
|
|
);
|
|
|
|
|
2023-03-07 03:47:18 +09:00
|
|
|
gulp.task("clean", function (done) {
|
2016-03-05 05:14:56 +09:00
|
|
|
console.log();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log("### Cleaning up project builds");
|
2016-03-05 05:14:56 +09:00
|
|
|
|
2023-03-07 03:47:18 +09:00
|
|
|
rimraf(BUILD_DIR, done);
|
2016-03-05 05:14:56 +09:00
|
|
|
});
|
|
|
|
|
2023-07-08 16:29:51 +09:00
|
|
|
gulp.task("importl10n", async function () {
|
|
|
|
const { downloadL10n } = await import("./external/importL10n/locales.mjs");
|
2016-03-05 05:14:56 +09:00
|
|
|
|
|
|
|
console.log();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log("### Importing translations from mozilla-central");
|
2016-03-05 05:14:56 +09:00
|
|
|
|
|
|
|
if (!fs.existsSync(L10N_DIR)) {
|
|
|
|
fs.mkdirSync(L10N_DIR);
|
|
|
|
}
|
2023-07-08 16:29:51 +09:00
|
|
|
await downloadL10n(L10N_DIR);
|
2016-03-05 05:14:56 +09:00
|
|
|
});
|
|
|
|
|
2021-06-04 19:30:09 +09:00
|
|
|
function ghPagesPrepare() {
|
2017-04-15 04:28:46 +09:00
|
|
|
console.log();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log("### Creating web site");
|
2017-04-15 04:28:46 +09:00
|
|
|
|
|
|
|
rimraf.sync(GH_PAGES_DIR);
|
|
|
|
|
|
|
|
return merge([
|
2023-07-24 00:54:13 +09:00
|
|
|
gulp
|
|
|
|
.src(GENERIC_DIR + "**/*", { base: GENERIC_DIR, removeBOM: false })
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
.pipe(gulp.dest(GH_PAGES_DIR)),
|
2023-07-24 00:54:13 +09:00
|
|
|
gulp
|
2021-02-10 02:28:48 +09:00
|
|
|
.src(GENERIC_LEGACY_DIR + "**/*", {
|
|
|
|
base: GENERIC_LEGACY_DIR,
|
2023-07-24 00:54:13 +09:00
|
|
|
removeBOM: false,
|
2021-02-10 02:28:48 +09:00
|
|
|
})
|
|
|
|
.pipe(gulp.dest(GH_PAGES_DIR + "legacy/")),
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp
|
|
|
|
.src(JSDOC_BUILD_DIR + "**/*", { base: JSDOC_BUILD_DIR })
|
|
|
|
.pipe(gulp.dest(GH_PAGES_DIR + "api/draft/")),
|
2017-04-15 04:28:46 +09:00
|
|
|
]);
|
2021-06-04 19:30:09 +09:00
|
|
|
}
|
2017-04-15 04:28:46 +09:00
|
|
|
|
2023-07-08 20:50:19 +09:00
|
|
|
gulp.task("wintersmith", async function () {
|
|
|
|
const { default: wintersmith } = await import("wintersmith");
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const env = wintersmith("docs/config.json");
|
2021-02-10 02:28:48 +09:00
|
|
|
|
2023-07-08 20:50:19 +09:00
|
|
|
return new Promise((resolve, reject) => {
|
|
|
|
env.build(GH_PAGES_DIR, function (error) {
|
|
|
|
if (error) {
|
|
|
|
reject(error);
|
|
|
|
return;
|
|
|
|
}
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
2023-07-08 20:50:19 +09:00
|
|
|
replaceInFile(
|
|
|
|
GH_PAGES_DIR + "/getting_started/index.html",
|
|
|
|
/STABLE_VERSION/g,
|
|
|
|
config.stableVersion
|
|
|
|
);
|
|
|
|
|
|
|
|
console.log("Done building with wintersmith.");
|
|
|
|
resolve();
|
|
|
|
});
|
2017-04-15 04:28:46 +09:00
|
|
|
});
|
|
|
|
});
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"web",
|
|
|
|
gulp.series(
|
|
|
|
"generic",
|
2021-02-10 02:28:48 +09:00
|
|
|
"generic-legacy",
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
"jsdoc",
|
2021-06-04 19:30:09 +09:00
|
|
|
ghPagesPrepare,
|
2023-04-28 01:04:07 +09:00
|
|
|
"wintersmith"
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
)
|
|
|
|
);
|
|
|
|
|
2022-09-03 20:05:59 +09:00
|
|
|
function packageJson() {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const VERSION = getVersionJSON().version;
|
2020-08-04 18:59:56 +09:00
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const DIST_NAME = "pdfjs-dist";
|
|
|
|
const DIST_DESCRIPTION = "Generic build of Mozilla's PDF.js library.";
|
|
|
|
const DIST_KEYWORDS = ["Mozilla", "pdf", "pdf.js"];
|
|
|
|
const DIST_HOMEPAGE = "http://mozilla.github.io/pdf.js/";
|
|
|
|
const DIST_BUGS_URL = "https://github.com/mozilla/pdf.js/issues";
|
|
|
|
const DIST_LICENSE = "Apache-2.0";
|
2020-08-04 18:59:56 +09:00
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const npmManifest = {
|
2020-07-23 05:38:04 +09:00
|
|
|
name: DIST_NAME,
|
|
|
|
version: VERSION,
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
main: "build/pdf.mjs",
|
2021-06-19 23:24:34 +09:00
|
|
|
types: "types/src/pdf.d.ts",
|
2020-07-23 05:38:04 +09:00
|
|
|
description: DIST_DESCRIPTION,
|
|
|
|
keywords: DIST_KEYWORDS,
|
|
|
|
homepage: DIST_HOMEPAGE,
|
|
|
|
bugs: DIST_BUGS_URL,
|
|
|
|
license: DIST_LICENSE,
|
2022-11-02 08:33:31 +09:00
|
|
|
optionalDependencies: {
|
2023-04-16 05:08:58 +09:00
|
|
|
canvas: "^2.11.2",
|
2023-01-23 01:01:06 +09:00
|
|
|
"path2d-polyfill": "^2.0.1",
|
2022-02-13 01:30:39 +09:00
|
|
|
},
|
2020-07-23 05:38:04 +09:00
|
|
|
browser: {
|
|
|
|
canvas: false,
|
|
|
|
fs: false,
|
|
|
|
http: false,
|
|
|
|
https: false,
|
|
|
|
url: false,
|
|
|
|
},
|
|
|
|
repository: {
|
|
|
|
type: "git",
|
|
|
|
url: DIST_REPO_URL,
|
|
|
|
},
|
2023-03-07 20:03:45 +09:00
|
|
|
engines: {
|
2023-04-05 17:40:19 +09:00
|
|
|
node: ">=18",
|
2023-03-07 20:03:45 +09:00
|
|
|
},
|
2020-07-23 05:38:04 +09:00
|
|
|
};
|
2020-08-04 18:59:56 +09:00
|
|
|
|
2022-09-03 20:05:59 +09:00
|
|
|
return createStringSource(
|
|
|
|
"package.json",
|
|
|
|
JSON.stringify(npmManifest, null, 2)
|
|
|
|
);
|
2020-07-23 05:38:04 +09:00
|
|
|
}
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"dist-pre",
|
|
|
|
gulp.series(
|
|
|
|
"generic",
|
2021-02-10 02:28:48 +09:00
|
|
|
"generic-legacy",
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
"components",
|
2021-02-10 02:28:48 +09:00
|
|
|
"components-legacy",
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
"image_decoders",
|
2021-02-10 02:28:48 +09:00
|
|
|
"image_decoders-legacy",
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
"minified",
|
2021-02-10 02:28:48 +09:00
|
|
|
"minified-legacy",
|
2020-07-23 05:38:04 +09:00
|
|
|
"types",
|
2021-06-03 22:44:17 +09:00
|
|
|
function createDist() {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Cloning baseline distribution");
|
|
|
|
|
|
|
|
rimraf.sync(DIST_DIR);
|
|
|
|
mkdirp.sync(DIST_DIR);
|
|
|
|
safeSpawnSync("git", ["clone", "--depth", "1", DIST_REPO_URL, DIST_DIR]);
|
|
|
|
|
|
|
|
console.log();
|
|
|
|
console.log("### Overwriting all files");
|
2023-03-07 03:47:18 +09:00
|
|
|
rimraf.sync(path.join(DIST_DIR, "*"));
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
|
|
|
return merge([
|
2022-09-03 20:05:59 +09:00
|
|
|
packageJson().pipe(gulp.dest(DIST_DIR)),
|
2023-07-24 00:54:13 +09:00
|
|
|
gulp
|
|
|
|
.src("external/dist/**/*", {
|
|
|
|
base: "external/dist",
|
|
|
|
removeBOM: false,
|
|
|
|
})
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
.pipe(gulp.dest(DIST_DIR)),
|
|
|
|
gulp.src(GENERIC_DIR + "LICENSE").pipe(gulp.dest(DIST_DIR)),
|
|
|
|
gulp
|
|
|
|
.src(GENERIC_DIR + "web/cmaps/**/*", { base: GENERIC_DIR + "web" })
|
|
|
|
.pipe(gulp.dest(DIST_DIR)),
|
2020-12-11 10:32:18 +09:00
|
|
|
gulp
|
|
|
|
.src(GENERIC_DIR + "web/standard_fonts/**/*", {
|
|
|
|
base: GENERIC_DIR + "web",
|
|
|
|
})
|
|
|
|
.pipe(gulp.dest(DIST_DIR)),
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp
|
|
|
|
.src([
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
GENERIC_DIR + "build/{pdf,pdf.worker,pdf.sandbox}.mjs",
|
|
|
|
GENERIC_DIR + "build/{pdf,pdf.worker,pdf.sandbox}.mjs.map",
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
SRC_DIR + "pdf.worker.entry.js",
|
|
|
|
])
|
|
|
|
.pipe(gulp.dest(DIST_DIR + "build/")),
|
2019-10-15 04:19:31 +09:00
|
|
|
gulp
|
|
|
|
.src([
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
GENERIC_LEGACY_DIR + "build/{pdf,pdf.worker,pdf.sandbox}.mjs",
|
|
|
|
GENERIC_LEGACY_DIR + "build/{pdf,pdf.worker,pdf.sandbox}.mjs.map",
|
2019-10-15 04:19:31 +09:00
|
|
|
SRC_DIR + "pdf.worker.entry.js",
|
|
|
|
])
|
2021-02-10 02:28:48 +09:00
|
|
|
.pipe(gulp.dest(DIST_DIR + "legacy/build/")),
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.src(MINIFIED_DIR + "build/pdf.mjs")
|
|
|
|
.pipe(rename("pdf.min.mjs"))
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
.pipe(gulp.dest(DIST_DIR + "build/")),
|
|
|
|
gulp
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.src(MINIFIED_DIR + "build/pdf.worker.mjs")
|
|
|
|
.pipe(rename("pdf.worker.min.mjs"))
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
.pipe(gulp.dest(DIST_DIR + "build/")),
|
2021-01-27 00:34:19 +09:00
|
|
|
gulp
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.src(MINIFIED_DIR + "build/pdf.sandbox.mjs")
|
|
|
|
.pipe(rename("pdf.sandbox.min.mjs"))
|
2021-01-27 00:34:19 +09:00
|
|
|
.pipe(gulp.dest(DIST_DIR + "build/")),
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.src(MINIFIED_DIR + "image_decoders/pdf.image_decoders.mjs")
|
|
|
|
.pipe(rename("pdf.image_decoders.min.mjs"))
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
.pipe(gulp.dest(DIST_DIR + "image_decoders/")),
|
2020-08-17 21:57:30 +09:00
|
|
|
gulp
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.src(MINIFIED_LEGACY_DIR + "build/pdf.mjs")
|
|
|
|
.pipe(rename("pdf.min.mjs"))
|
2021-02-10 02:28:48 +09:00
|
|
|
.pipe(gulp.dest(DIST_DIR + "legacy/build/")),
|
2020-08-17 21:57:30 +09:00
|
|
|
gulp
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.src(MINIFIED_LEGACY_DIR + "build/pdf.worker.mjs")
|
|
|
|
.pipe(rename("pdf.worker.min.mjs"))
|
2021-02-10 02:28:48 +09:00
|
|
|
.pipe(gulp.dest(DIST_DIR + "legacy/build/")),
|
2021-01-27 00:34:19 +09:00
|
|
|
gulp
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.src(MINIFIED_LEGACY_DIR + "build/pdf.sandbox.mjs")
|
|
|
|
.pipe(rename("pdf.sandbox.min.mjs"))
|
2021-02-10 02:28:48 +09:00
|
|
|
.pipe(gulp.dest(DIST_DIR + "legacy/build/")),
|
2020-08-17 21:57:30 +09:00
|
|
|
gulp
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
.src(MINIFIED_LEGACY_DIR + "image_decoders/pdf.image_decoders.mjs")
|
|
|
|
.pipe(rename("pdf.image_decoders.min.mjs"))
|
2021-02-10 02:28:48 +09:00
|
|
|
.pipe(gulp.dest(DIST_DIR + "legacy/image_decoders/")),
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp
|
|
|
|
.src(COMPONENTS_DIR + "**/*", { base: COMPONENTS_DIR })
|
|
|
|
.pipe(gulp.dest(DIST_DIR + "web/")),
|
2019-10-15 04:19:31 +09:00
|
|
|
gulp
|
2021-02-10 02:28:48 +09:00
|
|
|
.src(COMPONENTS_LEGACY_DIR + "**/*", { base: COMPONENTS_LEGACY_DIR })
|
|
|
|
.pipe(gulp.dest(DIST_DIR + "legacy/web/")),
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp
|
|
|
|
.src(IMAGE_DECODERS_DIR + "**/*", { base: IMAGE_DECODERS_DIR })
|
2020-08-17 21:30:09 +09:00
|
|
|
.pipe(gulp.dest(DIST_DIR + "image_decoders/")),
|
|
|
|
gulp
|
2021-02-10 02:28:48 +09:00
|
|
|
.src(IMAGE_DECODERS_LEGACY_DIR + "**/*", {
|
|
|
|
base: IMAGE_DECODERS_LEGACY_DIR,
|
2020-08-17 21:30:09 +09:00
|
|
|
})
|
2021-02-10 02:28:48 +09:00
|
|
|
.pipe(gulp.dest(DIST_DIR + "legacy/image_decoders/")),
|
2020-08-04 18:59:56 +09:00
|
|
|
gulp
|
|
|
|
.src(TYPES_DIR + "**/*", { base: TYPES_DIR })
|
|
|
|
.pipe(gulp.dest(DIST_DIR + "types/")),
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
]);
|
|
|
|
}
|
|
|
|
)
|
|
|
|
);
|
|
|
|
|
|
|
|
gulp.task(
|
|
|
|
"dist-install",
|
2021-06-03 22:44:17 +09:00
|
|
|
gulp.series("dist-pre", function createDistInstall(done) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
let distPath = DIST_DIR;
|
|
|
|
const opts = {};
|
|
|
|
const installPath = process.env.PDFJS_INSTALL_PATH;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
if (installPath) {
|
|
|
|
opts.cwd = installPath;
|
|
|
|
distPath = path.relative(installPath, distPath);
|
|
|
|
}
|
2023-04-20 23:09:13 +09:00
|
|
|
safeSpawnSync("npm", ["install", distPath], opts);
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
done();
|
|
|
|
})
|
|
|
|
);
|
2017-04-19 04:00:53 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
2021-06-04 19:30:09 +09:00
|
|
|
"dist",
|
|
|
|
gulp.series("dist-pre", function createDist(done) {
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const VERSION = getVersionJSON().version;
|
2019-02-10 01:21:27 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Committing changes");
|
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
let reason = process.env.PDFJS_UPDATE_REASON;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
// Attempt to work-around the broken link, see https://github.com/mozilla/pdf.js/issues/10391
|
|
|
|
if (typeof reason === "string") {
|
2021-05-16 17:58:34 +09:00
|
|
|
const reasonParts =
|
|
|
|
/^(See )(mozilla\/pdf\.js)@tags\/(v\d+\.\d+\.\d+)\s*$/.exec(reason);
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
|
|
|
if (reasonParts) {
|
|
|
|
reason =
|
|
|
|
reasonParts[1] +
|
|
|
|
"https://github.com/" +
|
|
|
|
reasonParts[2] +
|
|
|
|
"/releases/tag/" +
|
|
|
|
reasonParts[3];
|
|
|
|
}
|
2019-02-10 01:21:27 +09:00
|
|
|
}
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const message =
|
|
|
|
"PDF.js version " + VERSION + (reason ? " - " + reason : "");
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
safeSpawnSync("git", ["add", "*"], { cwd: DIST_DIR });
|
|
|
|
safeSpawnSync("git", ["commit", "-am", message], { cwd: DIST_DIR });
|
|
|
|
safeSpawnSync("git", ["tag", "-a", "v" + VERSION, "-m", message], {
|
|
|
|
cwd: DIST_DIR,
|
|
|
|
});
|
2017-04-19 04:00:53 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log();
|
|
|
|
console.log("Done. Push with");
|
|
|
|
console.log(
|
2019-12-26 04:03:46 +09:00
|
|
|
" cd " + DIST_DIR + "; git push --tags " + DIST_REPO_URL + " master"
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
|
|
|
console.log();
|
|
|
|
done();
|
|
|
|
})
|
|
|
|
);
|
2017-04-19 04:00:53 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"mozcentralbaseline",
|
2021-06-04 19:30:09 +09:00
|
|
|
gulp.series(createBaseline, function createMozcentralBaseline(done) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Creating mozcentral baseline environment");
|
2017-02-04 23:19:46 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
// Create a mozcentral build.
|
|
|
|
rimraf.sync(BASELINE_DIR + BUILD_DIR);
|
2016-03-05 00:36:46 +09:00
|
|
|
|
Enable the ESLint `no-var` rule in `gulpfile.js`
Given that `let`/`const` is already used here and there in this file, converting the rest of the `var` occurrences shouldn't be a problem.
Note that the majority of these changes were done automatically, by using the `gulp lint --fix` command, and the manual changes were limited to the following diff:
```diff
diff --git a/gulpfile.js b/gulpfile.js
index e2360c8ec..905420c33 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -676,8 +676,8 @@ gulp.task("default_preferences-pre", function () {
],
}).code;
}
- var babel = require("@babel/core");
- var ctx = {
+ const babel = require("@babel/core");
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: builder.merge(DEFINES, {
@@ -690,7 +690,7 @@ gulp.task("default_preferences-pre", function () {
"pdfjs-lib": "../pdf",
},
};
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(["web/{app_options,viewer_compatibility}.js"], {
base: ".",
@@ -1418,14 +1418,14 @@ function buildLib(defines, dir) {
});
return licenseHeaderLibre + content;
}
- var babel = require("@babel/core");
+ const babel = require("@babel/core");
const versionInfo = getVersionJSON();
- var bundleDefines = builder.merge(defines, {
+ const bundleDefines = builder.merge(defines, {
BUNDLE_VERSION: versionInfo.version,
BUNDLE_BUILD: versionInfo.commit,
TESTING: process.env.TESTING === "true",
});
- var ctx = {
+ const ctx = {
rootPath: __dirname,
saveComments: false,
defines: bundleDefines,
@@ -1433,10 +1433,10 @@ function buildLib(defines, dir) {
"pdfjs-lib": "../pdf",
},
};
- var licenseHeaderLibre = fs
+ const licenseHeaderLibre = fs
.readFileSync("./src/license_header_libre.js")
.toString();
- var preprocessor2 = require("./external/builder/preprocessor2.js");
+ const preprocessor2 = require("./external/builder/preprocessor2.js");
return merge([
gulp.src(
[
```
2021-03-13 19:42:40 +09:00
|
|
|
const workingDirectory = path.resolve(process.cwd(), BASELINE_DIR);
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
safeSpawnSync("gulp", ["mozcentral"], {
|
|
|
|
env: process.env,
|
|
|
|
cwd: workingDirectory,
|
|
|
|
stdio: "inherit",
|
|
|
|
});
|
2017-04-28 04:42:07 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
// Copy the mozcentral build to the mozcentral baseline directory.
|
|
|
|
rimraf.sync(MOZCENTRAL_BASELINE_DIR);
|
|
|
|
mkdirp.sync(MOZCENTRAL_BASELINE_DIR);
|
2017-04-28 04:42:07 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp
|
|
|
|
.src([BASELINE_DIR + BUILD_DIR + "mozcentral/**/*"])
|
2017-04-28 04:42:07 +09:00
|
|
|
.pipe(gulp.dest(MOZCENTRAL_BASELINE_DIR))
|
2020-04-14 19:28:14 +09:00
|
|
|
.on("end", function () {
|
2017-04-28 04:42:07 +09:00
|
|
|
// Commit the mozcentral baseline.
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
safeSpawnSync("git", ["init"], { cwd: MOZCENTRAL_BASELINE_DIR });
|
|
|
|
safeSpawnSync("git", ["add", "."], { cwd: MOZCENTRAL_BASELINE_DIR });
|
|
|
|
safeSpawnSync("git", ["commit", "-m", '"mozcentral baseline"'], {
|
|
|
|
cwd: MOZCENTRAL_BASELINE_DIR,
|
|
|
|
});
|
2017-04-28 04:42:07 +09:00
|
|
|
done();
|
|
|
|
});
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
})
|
|
|
|
);
|
2016-03-05 00:36:46 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
|
|
|
"mozcentraldiff",
|
2021-06-03 22:44:17 +09:00
|
|
|
gulp.series(
|
|
|
|
"mozcentral",
|
|
|
|
"mozcentralbaseline",
|
|
|
|
function createMozcentralDiff(done) {
|
|
|
|
console.log();
|
|
|
|
console.log("### Creating mozcentral diff");
|
2017-04-28 05:59:45 +09:00
|
|
|
|
2021-06-03 22:44:17 +09:00
|
|
|
// Create the diff between the current mozcentral build and the
|
|
|
|
// baseline mozcentral build, which both exist at this point.
|
|
|
|
// The mozcentral baseline directory is a Git repository, so we
|
|
|
|
// remove all files and copy the current mozcentral build files
|
|
|
|
// into it to create the diff.
|
2023-03-07 03:47:18 +09:00
|
|
|
rimraf.sync(MOZCENTRAL_BASELINE_DIR + "*");
|
2017-04-28 05:59:45 +09:00
|
|
|
|
2021-06-03 22:44:17 +09:00
|
|
|
gulp
|
|
|
|
.src([BUILD_DIR + "mozcentral/**/*"])
|
|
|
|
.pipe(gulp.dest(MOZCENTRAL_BASELINE_DIR))
|
|
|
|
.on("end", function () {
|
|
|
|
safeSpawnSync("git", ["add", "-A"], { cwd: MOZCENTRAL_BASELINE_DIR });
|
|
|
|
const diff = safeSpawnSync(
|
|
|
|
"git",
|
|
|
|
["diff", "--binary", "--cached", "--unified=8"],
|
|
|
|
{ cwd: MOZCENTRAL_BASELINE_DIR }
|
|
|
|
).stdout;
|
|
|
|
|
|
|
|
createStringSource(MOZCENTRAL_DIFF_FILE, diff)
|
|
|
|
.pipe(gulp.dest(BUILD_DIR))
|
|
|
|
.on("end", function () {
|
|
|
|
console.log(
|
|
|
|
"Result diff can be found at " +
|
|
|
|
BUILD_DIR +
|
|
|
|
MOZCENTRAL_DIFF_FILE
|
|
|
|
);
|
|
|
|
done();
|
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
)
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
|
|
|
|
2020-04-14 19:28:14 +09:00
|
|
|
gulp.task("externaltest", function (done) {
|
2020-10-05 00:30:39 +09:00
|
|
|
console.log();
|
|
|
|
console.log("### Running test-fixtures.js");
|
2023-07-08 23:07:54 +09:00
|
|
|
safeSpawnSync("node", ["external/builder/test-fixtures.mjs"], {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
stdio: "inherit",
|
|
|
|
});
|
2020-10-05 00:30:39 +09:00
|
|
|
|
|
|
|
console.log();
|
|
|
|
console.log("### Running test-fixtures_esprima.js");
|
2023-07-08 23:07:54 +09:00
|
|
|
safeSpawnSync("node", ["external/builder/test-fixtures_esprima.mjs"], {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
stdio: "inherit",
|
|
|
|
});
|
2018-11-19 02:33:23 +09:00
|
|
|
done();
|
2017-05-04 02:16:37 +09:00
|
|
|
});
|
2019-12-19 05:26:44 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
gulp.task(
|
2021-08-27 23:07:07 +09:00
|
|
|
"ci-test",
|
2023-06-25 22:21:03 +09:00
|
|
|
gulp.series(
|
|
|
|
gulp.parallel("lint", "externaltest", "unittestcli"),
|
2023-08-31 22:26:31 +09:00
|
|
|
"lint-chromium",
|
|
|
|
"typestest"
|
2023-06-25 22:21:03 +09:00
|
|
|
)
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|