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
anddist
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
anddist
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
- https://github.com/parcel-bundler/parcel/issues/7645 — committed to navikt/aap-soknad by tidnav 2 years ago
- Added workaround for parcel lmdb issue: https://github.com/parcel-bundler/parcel/issues/7645 — committed to JennaSys/pyuseref by JennaSys 2 years ago
- Disable swapping target buffer optimization to address https://github.com/parcel-bundler/parcel/issues/7645 for now — committed to kriszyp/lmdb-js by kriszyp 2 years ago
- Use better initialization approach to compression, don't replace dictionary buffer on each large decompression and fix check for restoring buffer when using compression, https://github.com/parcel-bund... — committed to kriszyp/lmdb-js by kriszyp 2 years ago
- Update dependencies with `npm update`. Fix parcel bug. See: https://github.com/parcel-bundler/parcel/issues/7645 — committed to ZeLonewolf/openstreetmap-americana by adamfranco 2 years ago
I can confirm that reverting lmdb fixes the build.
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.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
to0x100000
and the build worked where it was failing before. Changing it back made it fail again, so it was repeatable.cc. @kriszyp
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 andyarn 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:
It works with
serve
but notbuild
.This build command fails:
If I remove the
--no-source-maps
option from the build command it works: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