search

diegomura / react-pdf

📄 Create PDF files using React
https://react-pdf.org
MIT License
14.22k stars 1.11k forks source link

Fixed `.yml` build error caused by ternary in script name for `e2e-node` #2690

Open joelybahh opened 1 month ago

joelybahh commented 1 month ago

Screenshot 2024-03-27 at 11 20 19 am In response to the above error, which seems to have been triggered after my recent PR merge, I removed the ternary from the name. At a glance, this appears to be for vanity purposes anyway.

changeset-bot[bot] commented 1 month ago

🦋 Changeset detected

Latest commit: cb53e4e946f012230e6f56dffb1f2d487750c1d5

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 7 packages | Name | Type | | ----------------------- | ----- | | @react-pdf/pdfkit | Patch | | @react-pdf/layout | Patch | | @react-pdf/renderer | Patch | | @react-pdf/svgkit | Patch | | @react-pdf/examples | Patch | | @react-pdf/e2e-node-cjs | Patch | | @react-pdf/e2e-node-esm | Patch |

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

joelybahh commented 1 month ago

I thought this was a simple change because of small syntax error, looks like a can of worms I wasn't ready for 😅

joelybahh commented 1 month ago

Could the E2E tests output be different now that this.bits is correctly being set?

ranma42 commented 1 month ago

Could the E2E tests output be different now that this.bits is correctly being set?

That does not seem to be the cause, as there are no images involved in the test. Additionally, in my environment the same diff is also detected running the tests on 6ffd1b96f5962f7abfb2e19d6249f1b5b519477e (right before the JPEG change). The very same issue seems to be even present since the very beginning of the e2e tests 021c354ab834cfef30c3a95a618017f1d626ab87.

The difference seems to be in the encoding of the deflated stream (deflating the streams in reference.pdf and the test output using qpdf results in identical files, excepts for the "moving parts").

This makes me believe that the difference is caused by a change in the output of the zlib compression, rather than by the JPEG fix. Unfortunately I was unable to find a knob to disable compression (except using the deprecated renderToString).

wojtekmaj commented 1 month ago

Duplicate of #2633