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.

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.

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.

/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.