Open chin2km opened 2 years ago
It seems it's happening only on ARM. We're debugging the same problem over here. Same codebase, works on Intel Mac, doesn't work on M1 Mac.
Our debugging so far showed that it's somewhat related to how parcel uses cache.
We have a massive file that exports around 1000 react components. When we comment all exports out, it works in a dev mode. Then if we uncomment group by group it still works. After uncommenting around 300 exports, it still works, then we stop the dev process, rm -rf .parcel-cache and again parcel throws that error OP posted.
It feels like there's some sort of overflow somewhere. Weird it's only on ARM though.
@sznowicki I can confirm most of that. This seems to happen only on M1 Mac. And ours is also a huge mono-repo with tons of JS and static assets file.
I also thought its mostly related to cache, but I run into the same issue even with --no-cache
flag.
Already tried things like setting PARCEL_WORKER_BACKEND=process
and PARCEL_WORKERS
and various combination of .parcelrc
but none seems to fix these issues.
From my observation "no-cache" makes it even worse. I suspect there's some weird memory problem. By "related to cache" I meant that if more is cached then problem disappears.
Now I got the same errors on my Intel Mac.
What changed is only we updated a dependency which holds all our corporate icons. The file count grew from ~1200 files to > 2400.
It worked until I changed the version of this dependency from 1.0.0-dev.1 to 1.0.0. From now on I get those unexpected undefined too.
Eventually I got it working:
ARM Mac fails consistently. It really feels like some odd race condition somewhere.
- start dev -> fail
- start again -> fail
- start again -> works
- remove .parcel-cache -> start again -> still works
same for me. But if you remove the dist
folder in addition to .parcel-cache
the fails starts over.
Overall in my tries I only had 10-20% success-rate when starting dev mode.
ARM Mac fails consistently
Same.
I have a project that ran fine on an M1 mac 16GB and get this error on an M1 mac 8GB...
We did some additional tests and it really seems like if you try enough times it eventually builds up enough cache to not expose this (probable) memory issue and start the dev process (with PARCEL_WORKER_BACKEND=process
).
We just tried it on Intel and ARM Macs. After 5 - 6 times of starting parcel
it finally took off.
Within one project with a lot of files using this flag PARCEL_WORKER_BACKEND=process
helps, but in the other which does not have this amount of files it does not help and the same issue appears.
I would say that this is a major bug related to the M1 architecture or some memory leak/optimization.
hye, just shiming in, but i'm trying to upgrade some outdated repo to current version of parcel, and in the process i stumble upon this too...
i'm on mac intel, so it's not just arm....
also suspect memory/file count/size related... not much else to suggest atm ... still digging
Still getting this issue on parcel v2.8.0. Any idea on how to fix?
Please share a reproduction if you have a situation where this happens consistently. That would help with getting this fixed
possible fix: https://github.com/parcel-bundler/parcel/pull/6644
possible fix: #6644
looking forward to this fix π
For me, it's the two for loops starting here:
the devDepRequest
object sometimes doesn't have invalidateOnFileChange
and/or invalidateOnFileCreate
and thus it throws that undefined error.
I just put an if block around each for those loops making sure the desired value exist and my code compiles fine.
@mischnic Hereβs a reproduction case for the error on the public repository. The issue only started appearing with the upgrade to 2.9.0 though.
I got (and FIXED) an extremely similar error ("Parcel build error got unexpected null") when I accidentally added ES6 syntax to a JavaScript file that had CommonJS syntax elsewhere. I added some ES6 "export" statements, when elsewhere in the file, my code was using a require(). I found which file was problematic by relocating all the files I suspected to a faraway folder, and then retrying the build. If the build worked, then I knew that all the remaining files were okay.
I added in the suspect files one by one, building after each add. When the build threw an error, I examined the newly added file and commented out all of its code - and then I built again (just to see if the build would work). I slowly uncommented the code until an error was triggered. By this process, I narrowed it down to two HTML files -> two modules -> two imports -> one import -> one file -> a couple of lines within the file and once I realised that I was mixing ES6 with commonJS, I fixed it and it worked just fine again. There isn't really a lot about this error online but I hope that if somebody sees this, it'll help them fix their error too.
Still getting this error on 2.10.0
I got this error when I mixed commonJS imports and ES6 syntax in one of the files in my projects last year. Maybe just check that you're not making the same mistake as me. I created a duplicate of my project and then ran the duplicate (reproducing the error), then I moved parts of my project to my Desktop folder by folder until there was no "unexpected undefined" error.
Then, I knew that the "corrupted" files were in the folders I removed; so I put the folders back one by one until the unexpected undefined error occurred again. That helped me identify which folder was corrupted. Then, inside of the "criminal" folder, I moved the files to my Desktop one by one until the unexpected undefined error no longer occurred; then I knew that the corrupted file was amongst the ones I removed, so I put them back in one by one until I got the error again.
When I got the error again, I had found the messed up file, and I scanned it for any irregularities. I had mixed features specific to CommonJS and features specific to ES6 in the file. Once I fixed those to be ONE of the two but not both, my files bundled correctly.
On Wed, 10 Apr 2024 at 15:03, Tom Adler @.***> wrote:
Still getting this error on v2.12.0 https://github.com/BTE-Trusted-Entity/didsign.io/pull/154
β Reply to this email directly, view it on GitHub https://github.com/parcel-bundler/parcel/issues/8375#issuecomment-2047365356, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ4PSPTVE3YLDPAI6FKCHGTY4UTALAVCNFSM554FXQ62U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBUG4ZTMNJTGU3A . You are receiving this because you commented.Message ID: @.***>
While it could help in some codebases, itβs not the case in 3 of mine projects, so a cleanup is not a solution :(
Just adding my two cents here.
In my case the problem was hit in a library that re-exports folders. Ie. ComponentGroup/component/componentItems.
If some component in components items imports everything from /ComponentGroup you may hit this. Maybe, because at some point it can't determine the correct order for dependencies.
Fixed that importing each dependency from their correct folder: from ComponentGroup, ComponentGroup/component instead everything from ComponentGroup.
π bug report
Trying to migrate a very large repository (private to a company) from webpack to parcel, I'm facing this frequent build error
Error: Got unexpected undefined
when runningparcel watch
and the error log doesn't say much more than that. After adding some manual error logging at the source in parcel core in node module I have some more info. Its getting thrown when running svg,jpg,png files through thecompressors
in this function in @pracel/core.We loved parcel in our tests and plan to use
parcel
in dev mode as of now (with plan to use in production later), but this error blocks us. Tried several fixes suggestion from various issues in the repo already but none seems to fix this particular issue.Any suggestions/help to get around this is highly appreciated.
example complete error
The error happens when the svg,jpg,png files are run through
@parcel/compressor-raw
. Is there a way to skip using any compressor at all during dev mode?.parcelrc
π Configuration (.babelrc, package.json, cli command)
package.json
π€ Expected Behavior
No errors in final compression stage
π― Current Behavior
Described above
π Possible Solution
A Way to skip
compressors
for file globs?π¦ Context
We are trying a build a very large server rendered react application with parcel.
π» Code Sample
Happens in a private repo.
π Your Environment