parcel: Inconsistent Build Behavior & Errors While Building

šŸ› bug report

I’m getting inconsistent build behavior. I get errors every time. But if I start making modifications to files, sometimes the build will succeed. Once it succeeds once, subsequent builds succeed. However, when debugging in Chrome, the debugger’s position is out of sync with the file contents (I can tell that it’s executing a different line than the UI indicates).

Once I get a successful build, I can quit and then attempt the build again and it will succeed, albeit with the above oddities. Clearing the output folder and cache takes me back to a non-buildable state (with the same source files).

I really hate bringing this to your team without a reproducible sample in-hand, but I’ve been searching and working on this issue for hours now and haven’t made any meaningful progress towards understanding the issue or narrowing it down. I intend to ask some other engineers to build it in the morning to try to narrow it down further—maybe it’s an environmental issue, though it seems somewhat unlikely.

šŸŽ› Configuration (.babelrc, package.json, cli command)

Running yarn parcel test-index.html

//tsconfig.json
{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "outDir": "out",
        "sourceMap": true
    }
}
//.parcelrc
{
  "extends": "@parcel/config-default",
  "transformers": {
    "*.{ts,tsx}": ["@parcel/transformer-typescript-tsc"]
  }
}

šŸ¤” Expected Behavior

Expected it to build/launch.

😯 Current Behavior

I’m getting the following error…

Server running at http://localhost:1234
ā ¼ Bundling...
node:internal/streams/buffer_list:97
    return this.head.data;
                     ^

TypeError: Cannot read properties of null (reading 'data')
    at BufferList.first (node:internal/streams/buffer_list:97:22)
    at howMuchToRead (node:internal/streams/readable:385:27)
    at TapStream.Readable.read (node:internal/streams/readable:430:7)
    at flow (node:internal/streams/readable:1012:34)
    at resume_ (node:internal/streams/readable:993:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

The precise text before the error varies (e.g. bundling, bundling runtime, packaging test-index.html, etc.).

šŸ’ Possible Solution

I’m at a complete loss. I’ve never experienced this with other parcel-based typescript projects.

šŸ”¦ Context

I’m working on porting and TypeScript-ifying a large JavaScript library intended for the browser. I reached a point where I felt like it was ready to put through it’s paces, but then hit this hurdle.

šŸ’» Code Sample

I tried to pare this down to something that I could share or even narrow down the culprit. I tried deleting large hunks of code and building. Eventually I did get it to work. But then when clearing .parcel-cache and dist subsequent builds didn’t work. So there seems to be some state at play other than just ā€œwhat do the files look like on diskā€ that I’ve been unable to pin down.

Since I can’t provide the environment, I want to at least describe the stateful behavior I’m seeing…

  • Delete .parcel-cache and dist
  • yarn parcel test-index.html
Server running at http://localhost:1234
ā “ Optimizing test-index.[hash].js...
node:internal/streams/buffer_list:97
    return this.head.data;
                     ^

TypeError: Cannot read properties of null (reading 'data')
    at BufferList.first (node:internal/streams/buffer_list:97:22)
    at howMuchToRead (node:internal/streams/readable:385:27)
    at TapStream.Readable.read (node:internal/streams/readable:430:7)
    at flow (node:internal/streams/readable:1012:34)
    at resume_ (node:internal/streams/readable:993:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
error Command failed with exit code 1.
  • Comment out an entire file (even though it’s referenced elsewhere and so it creates an error in the code)
  • yarn parcel test-index.html
Server running at http://localhost:1234
√ Built in 2.13s
  • Uncomment that file and save it
Server running at http://localhost:1234
√ Built in 586ms
  • CTRL+C
  • yarn parcel test-index.html
Server running at http://localhost:1234
√ Built in 22ms
  • CTRL+C
  • Delete .parcel-cache and dist
  • yarn parcel test-index.html
Server running at http://localhost:1234
ā ¼ Building runtime-6bd5baf8476e8c86.js...
node:internal/streams/buffer_list:97
    return this.head.data;
                     ^

TypeError: Cannot read properties of null (reading 'data')
    at BufferList.first (node:internal/streams/buffer_list:97:22)
    at howMuchToRead (node:internal/streams/readable:385:27)
    at TapStream.Readable.read (node:internal/streams/readable:430:7)
    at flow (node:internal/streams/readable:1012:34)
    at resume_ (node:internal/streams/readable:993:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
error Command failed with exit code 1.

That’s probably much more info than is truly useful…

šŸŒ Your Environment

Software Version(s)
Parcel 2.0.1
Node 16.13.2
yarn 1.22.15
Operating System Windows 10
TypeScript 4.5.4

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 24 (8 by maintainers)

Commits related to this issue

Most upvoted comments

I can confirm that reverting lmdb fixes the build.

  "resolutions": {
    "lmdb": "2.1.7"
  }

OK, I think I may have found the culprit. By comparing the package-lock.json files between a recent build and an older working build of the same project, it’s the lmdb dependency that is apparently causing the issue. It was updated to version 2.2.0 in the last few days.

Pinning this dependency to 2.1.7 makes my Parcel build work again.

  "devDependencies": {
    "lmdb": "2.1.7",
    "parcel": "^2.2.1"
  }

It appears to be a dependency of @parcel/cache which has it as "lmdb": "^2.0.2"

@antoinne85 can you see if this fixes it for you as well?

@JennaSys Thank you for checking on this for me. I actually still have no idea what is going wrong, I can’t see how this would be failing, but I will release a new version with this optimization disabled, until I can figure it out.

That’s fantastic - and thanks for the quick turnaround @kriszyp!

@JennaSys Thank you! I was able to reproduce this with your directions, and I believe I was able to implement a proper fix for the optimization (will release in v2.2.2, but v2.2.1 should be safe for now).

@kriszyp I can confirm that increasing the threshold value in /node_modules/lmdb/dist/index.cjs does fix the issue in my case. I changed it from 0x10000 to 0x100000 and the build worked where it was failing before. Changing it back made it fail again, so it was repeatable.

Pulling the thread that @JennaSys found… If I add the --no-source-maps flag, suddenly it builds successfully. And this is repeatable and predictable on the same source files.

So yarn parcel test-index.html will fail and yarn parcel test-index.html --no-source-maps will succeed. The behavior remains the same even if I leave .parcel-cache intact while switching back-and-forth between commands.

I am getting this same exact error:

ā  Optimizing index.[hash].js...
node:internal/streams/buffer_list:97
    return this.head.data;
                     ^

TypeError: Cannot read properties of null (reading 'data')
    at BufferList.first (node:internal/streams/buffer_list:97:22)
    at howMuchToRead (node:internal/streams/readable:385:27)
    at TapStream.Readable.read (node:internal/streams/readable:430:7)
    at flow (node:internal/streams/readable:1012:34)
    at resume_ (node:internal/streams/readable:993:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
Software Version(s)
Parcel 2.2.1
Node 16.13.2
npm 8.1.2
Operating System Linux Mint 19.3

It works with serve but not build.

This build command fails:

"build": "NODE_ENV=production parcel build --no-source-maps src/index.html"

If I remove the --no-source-maps option from the build command it works:

"build": "NODE_ENV=production parcel build src/index.html"

When I tried it on an Ubuntu 18.04 OS with Node 14.17.1 it worked with the --no-source-maps option.

Edit: I just tested it on Windows 10 with Node 15.14.0 and it also worked there with the --no-source-maps option. Edit2: It fails on MacOS with Node 16.13.1