Skip to content

Improve how the PDF.js version/commit information is exposed in the *built* files #19956

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Snuffleupagus
Copy link
Collaborator

@Snuffleupagus Snuffleupagus commented May 19, 2025

To make it easier to tell which PDF.js version/commit that the built files correspond to, they have (since many years) included pdfjsVersion and pdfjsBuild constants with that information.

As currently implemented this has a few shortcomings:

  • It requires manually adding the code, with its preprocessor statements, in all relevant files.

  • It requires ESLint disable statements, since it's obviously unused code.

  • Being unused, this code is removed in the minified builds.

  • This information would be more appropriate as comments, however Babel discards all comments during building.

  • It would be helpful to have this information at the top of the built files, however it's being moved during building.

To address all of these issues, we'll instead utilize Webpack to insert the version/commit information as a comment placed just after the license header.

@Snuffleupagus Snuffleupagus changed the title Improve the PDF.js version/commit information is exposed in the *built* files Improve how the PDF.js version/commit information is exposed in the *built* files May 19, 2025
…built* files

To make it easier to tell which PDF.js version/commit that the *built* files correspond to, they have (since many years) included `pdfjsVersion` and `pdfjsBuild` constants with that information.

As currently implemented this has a few shortcomings:
 - It requires manually adding the code, with its preprocessor statements, in all relevant files.

 - It requires ESLint disable statements, since it's obviously unused code.

 - Being unused, this code is removed in the minified builds.

 - This information would be more appropriate as comments, however Babel discards all comments during building.

 - It would be helpful to have this information at the top of the *built* files, however it's being moved during building.

To address all of these issues, we'll instead utilize Webpack to insert the version/commit information as a comment placed just after the license header.
@Snuffleupagus
Copy link
Collaborator Author

/botio-linux test

@moz-tools-bot
Copy link
Collaborator

From: Bot.io (Linux m4)


Received

Command cmd_test from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.241.84.105:8877/236d97279486376/output.txt

@moz-tools-bot
Copy link
Collaborator

From: Bot.io (Linux m4)


Failed

Full output at http://54.241.84.105:8877/236d97279486376/output.txt

Total script time: 30.09 mins

  • Unit tests: Passed
  • Integration Tests: FAILED
  • Regression tests: Passed

@Snuffleupagus Snuffleupagus added the release-blocker Blocker for the upcoming release label May 20, 2025
Copy link
Contributor

@calixteman calixteman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
other release-blocker Blocker for the upcoming release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants