Open mpmartinez-etsy opened 5 months ago
We are testing parcel for use as a javascript bundler, and wanted to prove out the utility of it
Also feel free to ask for help if you run into any other problems (e.g. regarding configuration), for example in the Github Discussions or on Discord!
This is apparently an infinite recursion in the resolver when resolving preact/compat
with preact@10.13.1
frame #1088: 0x00000001700383e4 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_directory::ha2f04ad6884058f7(self=0x00007000113ddf00, dir=&std::path::Path @ 0x0000700011297f30, parent_package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011297f40) at lib.rs:1066:13
frame #1089: 0x0000000170040410 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_path::h88788c6ab2097b24(self=0x00007000113ddf00, path=&std::path::Path @ 0x0000700011298178, package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011298188) at lib.rs:814:14
frame #1090: 0x000000017003bae7 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::try_package_entries::h4c6361f3dd113d58(self=0x00007000113ddf00, package=0x0000000103fd4600) at lib.rs:774:26
frame #1091: 0x00000001700383e4 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_directory::ha2f04ad6884058f7(self=0x00007000113ddf00, dir=&std::path::Path @ 0x0000700011298730, parent_package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011298740) at lib.rs:1066:13
frame #1092: 0x0000000170040410 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_path::h88788c6ab2097b24(self=0x00007000113ddf00, path=&std::path::Path @ 0x0000700011298978, package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011298988) at lib.rs:814:14
frame #1093: 0x000000017003bae7 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::try_package_entries::h4c6361f3dd113d58(self=0x00007000113ddf00, package=0x0000000103fd4600) at lib.rs:774:26
frame #1094: 0x00000001700383e4 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_directory::ha2f04ad6884058f7(self=0x00007000113ddf00, dir=&std::path::Path @ 0x0000700011298f30, parent_package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011298f40) at lib.rs:1066:13
frame #1095: 0x0000000170040410 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_path::h88788c6ab2097b24(self=0x00007000113ddf00, path=&std::path::Path @ 0x0000700011299178, package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011299188) at lib.rs:814:14
frame #1096: 0x000000017003bae7 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::try_package_entries::h4c6361f3dd113d58(self=0x00007000113ddf00, package=0x0000000103fd4600) at lib.rs:774:26
frame #1097: 0x00000001700383e4 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_directory::ha2f04ad6884058f7(self=0x00007000113ddf00, dir=&std::path::Path @ 0x0000700011299730, parent_package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011299740) at lib.rs:1066:13
frame #1098: 0x0000000170040410 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_path::h88788c6ab2097b24(self=0x00007000113ddf00, path=&std::path::Path @ 0x0000700011299978, package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011299988) at lib.rs:814:14
frame #1099: 0x000000017003bae7 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::try_package_entries::h4c6361f3dd113d58(self=0x00007000113ddf00, package=0x0000000103fd4600) at lib.rs:774:26
It's actually unrelated to preact. This tsconfig
{
"compilerOptions": {
"paths": {
"preact/compat": [
"node_modules/@types/react",
"preact/compat"
]
}
}
}
includes https://unpkg.com/browse/@types/react@17.0.39/package.json
which in that specific version had a invalid "main": ""
entry. That causes the infinite loop
🐛 bug report
Heya folks, just thought I'd report there seems to be a deterministic segfault with this example repository. I've been able to reproduce this issue in every version of parcel from 2.90 to 2.12.0 (latest). I was able to reproduce this issue on Centos7 with node16.13.2, Ubuntu22.04.4 LTS with node20, and Mac OS X 14.2.1 with node16.20.2 - I'm happy to provide more information about any versions that are necessary, please let me know.
It's worth pointing out that this doesn't happen in parcel 2.8.3 - I haven't checked lower, as this version will be fine for our purposes.
Also, worth pointing out that while I did a cursory scan of previously open issues, and indeed found some closed that were related to segfaults, I couldn't find one describing this particular issue. Please feel free to close if this isn't relevant for your purposes.
🎛 Configuration (.babelrc, package.json, cli command)
provided in link above, but will paste here as well:
package.json:
tsconfig.json:
example.tsx:
build.mjs:
(no babel config was explicitly necessary to produce the above behavior)
🤔 Expected Behavior
Parcel shouldn't segfault (if something is wrong with the config, parcel should raise that up to the user).
😯 Current Behavior
Parcel segfaults with no additional information
💁 Possible Solution
none at this time
🔦 Context
We are testing parcel for use as a javascript bundler, and wanted to prove out the utility of it and hit this (admittedly with our rather arcane tsconfig/react/preact setup). We can drop down to a lower version to continue proving out utility, so no worries there, just figured that the reproducibility here might be useful
💻 Code Sample
https://github.com/mpmartinez-etsy/parcel-segfault-example
🌍 Your Environment