New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parcel memory leak crash after a few HMRs #1185
Comments
How big is your app, e.g. how many files + node_modules? |
Good question, any way to get parcel to spit it out?
|
@natew You could use this option https://parceljs.org/cli.html#print-a-detailed-report using a build command to get all the requires and sizes parcel processes. |
Ah cool will run that soon. It only crashes after using it for a few HMRs
so should be fine to print.
|
Not sure if this is super helpful, is there perhaps an expanded form flag to print? For reference, it was crashing before typeorm, even though that seems to take a lot of it up now. Profiling HMR specifically would be helpful, but not in the browser on the node side. I could maybe wrap some code to help see. |
I am also having this issue.
I can't print out a report because
Just running |
I also have a failing travis build. Note that running |
This seem to be related to #1513 |
I've had the same problem and my workaround has been to use I just created a super basic app (100 lines of code) with http://ant.design/ and firebase |
I have a similar problem. Along with random edit: I was running a client and server bundle at the same time, running one at a time helped |
Confirming this issue. Just got:
While I am not getting this particular message too consistently, parcel builds consistenly slow down over time when using HMR. This becomes noticeable as soon as after 15 min of normal development. It is not a big issue though, restarting parcel takes 10 seconds. My project is a React+Redux app, it has 773 folders in node_modules totaling about 100 MB. I can provide more info, if needed, but I cannot share the complete source code.
|
I reproduce this on master as well with a really long json file. |
It might be because we inline all the sources inside the sourcemap. Can you check using In Parcel 2 we keep the code in memory for a very short period of time so if we continue that pattern inside the sourcemaps (in combination with a streaming json stringifier), it would solve this issue (if that is the issue). |
@DeMoorJasper disabled source maps and it still seems to happen. Is there anyway to tell parcel "don't bundle this, I know what I'm doing"? |
@kennetpostigo not sure, in most stacktraces I saw in this issue it occurs in sourcemap-generator, so it is probably related to sourcemaps for those issues. If you could post your stacktrace it would help a lot (the one without sourcemaps) |
Hey guys, I ran into the same issue, my files are super simple, it's a regular javascript file and html file, and I just wanna set up a development server with HMR. I tried parcel index.html --no-cache not working, the error came up after several minutes. parcel index.html --no-source-maps not working, same issue. Parcel: 1.10.3 |
Experiencing the same issue. Codebase has a large number of dependencies which is what I imagine is causing the crash. |
Hey everyone!
I was including my own custom npm lib which was the size of more than 4MB build, and in both projects I used parcel. Now I have no error. Thanks |
I was running into a similar issue with a moderately large Parcel project. Parcel would consistently eat all of my RAM (6GB) whenever I started it. After reading through many issues I found this one. Using @DeMoorJasper's suggestion ( Is there a way to enable source maps just for my code and not for any code inside |
@embeddedt unfortunately not. Parcel 2 has a lot of improvements when it comes to ram usage, including only reading sourcefiles when needed for sourcemaps, which is when the sourcemaps get written if inline-sources is enabled which is only the default in production as we now mount the sources in the dev server. So it should be fixed for Parcel 2. Unfortunately there's no workaround for Parcel 1 besides turning of sourcemaps |
I see. That's too bad. Is Parcel 2 stable enough yet for production? I noticed that public testing opened up a few days ago. |
@embeddedt it's not stable enough to use in production. But any feedback and bugs discovered on larger codebases are very welcome |
It turns out that VSCode's function name autocompletion had inadvertently added an So my suggestion is: for those who are still using Parcel 1, check your bundles using |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. |
bug reprot
Basically, parcel 1.6 crashes pretty consistently for me when saving files in a medium-large app that uses HMR.
The stack is as follows:
🎛 Configuration (.babelrc, package.json, cli command)
🤔 Expected Behavior
Not crashing
Unfortunately, this one is hard for me to help you guys with without doing a more intense profile on the running process. The app is complex, and it only happens usually after a few HMRs.
Separately, tried updating to 1.7 but it won't run our stack anymore (forget the error).
🌍 Your Environment
The text was updated successfully, but these errors were encountered: