fix(base64_decode): throw on invalid input in every build

[josefguenther]

{{ "hello" | base64_decode }}

On master the node build renders garbage bytes (��e), and the browser builds throw atob's own error, whose message depends on the input and the runtime. Shopify/Liquid raises invalid base64 provided to base64_decode. This throws that error from a check both builds share, before decoding. {{ v | base64_decode }}:

v	master (node)	master (browser)	this PR (both)
"YWJj"	abc	abc	abc
"YWJjZA" (unpadded)	abcd	abcd	abcd
"YW Jj" (whitespace)	abc	abc	abc
"hello"	��e	RenderError: The string to be decoded is not correctly encoded.	RenderError: invalid base64 provided to base64_decode
"YWJj!!"	abc	RenderError: Invalid character	RenderError: invalid base64 provided to base64_decode
"-_-_" (URL-safe)	���	RenderError: Invalid character	RenderError: invalid base64 provided to base64_decode
5	(empty)	RenderError: The string to be decoded is not correctly encoded.	RenderError: invalid base64 provided to base64_decode

The check accepts exactly what atob accepts, so unpadded and whitespace-separated input still decodes in both builds. Shopify rejects those two as well, but rejecting them here would break input that works today.

The tests cover the node build in test/integration/filters/base64.spec.ts and the browser bundle in test/e2e/browser.spec.ts. npm run build, npm test (1676 tests) and npm run lint pass on Node 24.11.1.

Fixes #965

Written with AI assistance (Claude Code); I have reviewed the change.

[harttle]

Sorry for the late response. RenderError is expected for invalid input, as it is consistent with Shopify/liquid, FYI: this is what I get from the Ruby version:

"b25lIHR3byB0aHJlZQ=="    ok              "one two three"
"YWJj"                    ok              "abc"
"YWJjZA"                  unexpected_error  Liquid error: invalid base64 provided to base64_decode
"YW Jj"                   error           Liquid error: invalid base64 provided to base64_decode
"hello"                   error           Liquid error: invalid base64 provided to base64_decode
"invalidbase64"           error           Liquid error: invalid base64 provided to base64_decode
"YWJj!!"                  error           Liquid error: invalid base64 provided to base64_decode
"-_-_"                    error           Liquid error: invalid base64 provided to base64_decode
"!!!"                     error           Liquid error: invalid base64 provided to base64_decode
""                        ok              ""
5                         error           Liquid error: invalid base64 provided to base64_decode
{:a=>1}                   error           Liquid error: invalid base64 provided to base64_decode

What makes LiquidJS more consistent is to throw same errors for both browser and Node.js. But we also want to avoid too complicated or slow implementation as it's only an edge case. Otherwise I'd rather document it as a "difference from Shopify/liquid".

[josefguenther]

Thanks for running these through Ruby. Those "Liquid error: …" strings are what makes me think throwing doesn't match Shopify here. Shopify's default render writes that message in place of the failing tag, records the error, and renders the rest of the page. Only render! lets the error escape. So in Shopify, raising in these filters reports the bad value, and the page still renders.

LiquidJS fails the whole render on any error (catchAllErrors collects them but still throws at the end), so throwing here would match render! rather than render: one bad base64 value or %ff in a query string, which comes from the data and not the template, would take the whole page down. LiquidJS already keeps rendering in the same situation elsewhere: Shopify reports an error for divided_by: 0, and LiquidJS renders Infinity.

So I'd suggest keeping the render going, as Shopify does: an empty string here, U+FFFD for invalid UTF-8 in #970. The fully faithful version would be Shopify's model, where a filter error is kept to its own tag and reported, but that changes how every render error behaves, so it seemed beyond these PRs and maybe a better fit for v11. Happy to open an issue for that if it interests you.

[josefguenther]

By the way, I tested and Shopify reports an error for bad data in about a dozen filters (slice/truncate with a non-integer length, sort on mixed types, map on a non-array, …) and keeps rendering, and LiquidJS renders something for all of them; these two (#970/#971) would be the only ones that fail the render.

[harttle]

Thanks for the clarification.

• continue rendering should be a cross-filter feature. We can have a rethrowErrors switch for LiquidJS, while as for the filter itself, it should throw to allow error handling in higher level, like render and render! in Ruby.
• the divided_by: 0 case: I think we can fix it to align, as it won't require much complexity.

I see there can be many differences still. The principle would be: if it doesn't require a lot of complexity, we should align with Shopify; if there'd be a breaking change, we do it in v11 by adding the issue there; if it's not convenient for JS to implement, we document in the differences section.

[josefguenther]

Reworked: both builds now throw Shopify's invalid base64 provided to base64_decode, from one shared regex check. Unpadded and whitespace input still decode, since both builds accept them today. Added a browser-bundle test in test/e2e/browser.spec.ts and updated the title and description. I'll open a separate issue for rethrowErrors.