0.8.3 breaks @arethetypeswrong/cli

[remarkablemark]

How to reproduce

I'm using a package that has this library as a dependency and it started failing with the latest release.

See arethetypeswrong/arethetypeswrong.github.io#258

The problem

I'm running this command:

npx @arethetypeswrong/cli --pack

But it's failing with this error:

Error: Cannot read properties of undefined (reading 'filename')

Was there a breaking change in the latest release?

[101arrowz]

There should not have been any changes functional changes to gzip decompression, which is the only part of fflate that @arethetypeswrong/cli seems to use. But it definitely looks like there was some behavior change causing this breakage. I'm looking into it.

[remarkablemark]

Thanks @101arrowz! I opened an issue in the other repository in case they handled decompression in some weird way. In the meantime, I have a workaround where I set an overrides for fflate so no rush.

[101arrowz]

I think this is the same issue as a previous issue: #207. Essentially, fflate now rejects trailing zeros in a GZIP stream more consistently, which is leading to breakages for NPM package tarballs that often have trailing zeros.

This isn't a regression in fflate, but rather an unintentionally breaking change where the validation for GZIP streams became tighter in v0.8.3. The tarballs NPM provides are not strictly valid according to the GZIP specification, even when treated as multi-member streams, and the original solution I proposed in #207 to handle them was a "hack" that no longer passes the stricter validation. I could theoretically add support for trailing zeros in GZIP streams, but that would need to be a separate issue/feature request, and I do not consider it a bug in the library.

I was intending for this change to be made in v0.8.2, but it seems I messed up the tagging for that version and so I mistakenly assumed the changes in f787356 had already been released, when in reality they are only now being published. That's why this wasn't surfaced earlier.

I don't think this breakage will affect many users, as the situations in which v0.8.2 accepted trailing zeros in GZIP streams were already very specific. The following change replicates the error in v0.8.2.

import { Gunzip } from 'fflate';

const data = ... // some GZIP data with trailing zeros

const chunks = [];
const gunzip = new Gunzip(chunk => chunks.push(chunk));

// Instead of:
// gunzip.push(data, true);

gunzip.push(data, false);
gunzip.push(new Uint8Array(0), true);

// Now this throws an "invalid gzip data" error

As a result, I do not currently plan to revert this change, though I may add it to the docs.

There is a solution for @arethetypeswrong/cli that should work more consistently, however, and I will propose it in the issue you linked. Thank you for the report!

[101arrowz]

Actually, there is a separate issue causing the failure that is unrelated to this change and is not breaking per the API contract - @arethetypeswrong/cli was making an assumption about fflate's output dependent upon implementation details that have changed between patch versions. This is also fixable, and I'll send in a suggestion shortly.

[remarkablemark]

Makes sense and thanks for the update!