bug: aegir/fixtures loadFixtures incorrectly alters bytes in the browser

[SgtPooki]

Describe the bug

When using the loadFixtures function from aegir/fixtures in the browser, the bytes returned are incorrectly altered, causing test failures in https://github.com/SgtPooki/file-type.

Repro code in branch at https://github.com/SgtPooki/file-type/pull/new/repro/aegir-load-fixtures-browser-bug

To Reproduce
Steps to reproduce the behavior:

1. git clone https://github.com/SgtPooki/file-type
2. cd file-type
3. git checkout repro/aegir-load-fixtures-browser-bug
4. npm i && npm run test

Expected behavior
The browser tests pass, the same as they do in the node tests.

Screenshots

  1) fixture.tar.gz 65 .fileTypeFromBuffer() method - same fileType
  65 passing (605ms)
  1 failing
  1) fixture.tar.gz 65 .fileTypeFromBuffer() method - same fileType:

      AssertionError: expected 'tar' to equal 'gz'
      + expected - actual

      -tar
      +gz
      
      at checkBufferLike (/Users/sgtpooki/code/work/foss/SgtPooki/file-type/test/file-type.spec.ts:262:18)
      at testFromBuffer (/Users/sgtpooki/code/work/foss/SgtPooki/file-type/test/file-type.spec.ts:287:3)
      at Context2.<anonymous> (/Users/sgtpooki/code/work/foss/SgtPooki/file-type/test/file-type.spec.ts:349:9)

Desktop (please complete the following information):

• OS: macOS
• Browser: N/A
• Version: aegir@42.2.3

Additional context

The specific failing test can be ran by running npm run test -- -g 'fixture.tar.gz 65'. You'll see that the test passes in node, but fails in the browser test.

╰─ ✔ ❯ npm run test -- -g 'fixture.tar.gz 65'

> @sgtpooki/file-type@1.0.0 test
> aegir test -g fixture.tar.gz 65

build

> @sgtpooki/file-type@1.0.0 build
> npm run dep-check && aegir build


> @sgtpooki/file-type@1.0.0 dep-check
> aegir dep-check

  ✔ dependency-check
[12:12:52] tsc [started]
[12:12:52] tsc [completed]
[12:12:52] esbuild [started]
[12:12:52] esbuild [completed]
test node.js
Warning: Cannot find any files matching pattern "test/node.{js,cjs,mjs}"
Warning: Cannot find any files matching pattern "test/**/*.spec.{js,cjs,mjs}"


  ✔ fixture.tar.gz 65 .fileTypeFromBuffer() method - same fileType

  1 passing (12ms)

test browser
ℹ Browser "chromium" setup complete.

  1) fixture.tar.gz 65 .fileTypeFromBuffer() method - same fileType
  0 passing (147ms)
  1 failing
  1) fixture.tar.gz 65 .fileTypeFromBuffer() method - same fileType:

      AssertionError: expected 'tar' to equal 'gz'
      + expected - actual

      -tar
      +gz

      at checkBufferLike (/Users/sgtpooki/code/testing/SgtPooki/file-type/test/file-type.spec.ts:262:18)
      at testFromBuffer (/Users/sgtpooki/code/testing/SgtPooki/file-type/test/file-type.spec.ts:287:3)
      at Context2.<anonymous> (/Users/sgtpooki/code/testing/SgtPooki/file-type/test/file-type.spec.ts:349:9)

✘ Tests failed.
Command failed with exit code 1: /Users/sgtpooki/code/testing/SgtPooki/file-type/node_modules/.bin/pw-test test/**/*.spec.{js,cjs,mjs} test/browser.{js,cjs,mjs} dist/test/**/*.spec.{js,cjs,mjs} dist/test/browser.{js,cjs,mjs} --mode main --runner mocha --config /Users/sgtpooki/code/testing/SgtPooki/file-type/node_modules/aegir/src/config/pw-test.js --timeout=60000 --grep=fixture.tar.gz 65 --bail

[achingbrain]

I think the problem here is that your test loads a gzipped tarball, and something is decompressing it before returning it as the responseText property of the XMLHttpRequest object.

The bit-twiddling comes from here btw - unfortunately the bytes have already been decompressed by this point so the bug is not there.

[achingbrain]

I think the bug is in sirv, used by playwright-test to serve fixtures.

lukeed/sirv#158

A workaround is to just rename the .tar.gz file so it doesn't end in .gz.

[SgtPooki]

A workaround is to just rename the .tar.gz file so it doesn't end in .gz.

But the gz is the expected type, which returns correctly with a simple http server and piping fs.createReadStream

[SgtPooki]

Thanks for the quick responses and bugfix in playright-test

[achingbrain]

But the gz is the expected type, which returns correctly with a simple http server and piping fs.createReadStream

Renaming the file doesn't make it a different type, it just stops sirv setting the Content-Encoding header that causes fetch/XMLHttpRequest to decompress the bytes before making them available.

It's just a workaround to unblock you while the issue is fixed upstream.

[achingbrain]

Closing as a workaround has been released in hugomrdias/playwright-test#644 so this is usable now and the proper fix is discussed in lukeed/sirv#158