Use JSON imports rather than a custom Babel transform

[nicolo-ribaudo]

The Babel plugin has a custom JSON transform that replaces PDFJSDev.json("$ROOT/some/path.json") with the contents of some/path.json:

pdf.js/external/builder/babel-plugin-pdfjs-preprocessor.mjs

Lines 43 to 55 in c60c0d1

	case "json":
	if (!t.isStringLiteral(arg)) {
	throw new Error("Path to JSON is not provided");
	}
	let jsonPath = arg.value;
	if (jsonPath.startsWith(ROOT_PREFIX)) {
	jsonPath = joinPaths(
	ctx.rootPath,
	jsonPath.substring(ROOT_PREFIX.length)
	);
	}
	return JSON.parse(fs.readFileSync(jsonPath, "utf8"));
	}

This is only used once, in the Chromium extension code:

pdf.js/web/chromecom.js

Lines 197 to 199 in c60c0d1

	const i18nFileAccessLabel = PDFJSDev.json(
	"$ROOT/web/chrome-i18n-allow-access-to-file-urls.json"
	)[chrome.i18n.getUILanguage?.()];

There is a Stage 3 proposal that would allow directly importing JSON files:

import i18nFileAccessLabels from "./chrome-i18n-allow-access-to-file-urls.json" with { type: "json" };

This feature is already supported by default by Node.js, Chrome, Safari and Webpack. Given that the code where we use PDFJSDev.json is bundled with webpack, this syntax is safe to use and we can remove the custom PDFJSDev.json feature.

However, ESLint doesn't support this syntax yet because it's only a Stage 3 proposal and not part of the standard yet (it will hopefully become part of the standard in October). There are two options:

• wait until the first ESLint minor release after October, which will support this syntax by default
• use @babel/eslint-parser to let ESLint parse this syntax

[Snuffleupagus]

• wait until the first ESLint minor release after October, which will support this syntax by default

Given just how little that pre-processor feature is being used, this option seems overall less disruptive than making changes to our linting setup itself. (Especially since we should, at some point, switch to ESLint 9; which is being tracked in issue #17928.)