I’m using ffmpeg for audio processing in my code and that thing is 44mb. My repo has the embedded binary to prevent a huge install – but even if it didn’t and I pulled it from a CDN or something, I would be bumping up against ENOSPC anyway when npm tries to copy around that bin when it’s installed.
Any chance this could be bumped? From the faq:
If you get stuck trying to work within these limits, let us know! We’ll work something out for you.
So here I am 
What is your project name and do you mind if we take a look inside your container to see where your project currently is currently heavy in MBs?
Sure, project name is cold-part.
It’s not gonna even start though because the first thing the code needs to do is an npm install and just the /tmp copying will explode with an ENOSPC. The main culprit does seem to be the ffmpeg binary.
Thanks, we’ll take a look at it in bit and let you know if we can find out any workarounds. 
It looks like you’re using the zeo VR library, and that’s taking up a lot of space. When I install it here, it comes in around 220MB. Do you need that?
Yes, that’s the_only_ thing I need. I’m the author and I’m trying to get it running on Glitch. 
If you look at the individual files, you should see the cuplrit is a huge ffmpeg binary (required for handling stream processing) that is copied around by npm as part of the install. And that’s what bloats the size.
I’m going to optimize this down, but there’s no getting around the fact that there’s an ffmpeg binary, and I don’t know how to coax npm to not copy files when it installs a directory. Doing some math I don’t see how that can fit in less than 128 megs.
An alternative solution would be if ffmpeg was supplied by the glitch base or something.
Hm, I’m gonna try ditching the ffmpeg dependency entirely, just stream audio as F32 PCM’s. POC works.
That should save 40 mb times number of times npm copies stuff so I might be able to fit into 128 after all.
Hm, nope I’m still having trouble packing all of the modules into under 64 megs for everything (npm/yarn install effectively doubles the size requirements due to caching).
There’s no more binaries in there, just a ton of large-ish modules like THREE.js.
Any chance for a bump to 256 or so? Or for /tmp to not count against quota?
/tmp shouldn’t count against the quota. One thing you can do is to open your browser dev tools and run application.console(). This will open up a terminal connection to your container where you can poke around and see what’s taking up space.
Long term we have some ideas for improving the yarn/npm caching but it’ll be a while before we can implement them.
Hope this helps
Daniel’s added ffmpeg to the base image now, we hope it helps!
Oh wow. Yeah, having ffmpeg in base will definitely help me out.
Thanks!