I was just browsing my Nextcloud instance the other day when I wondered why the apps folder is so big. I quick check brought up, that many apps (maybe all of them) ship JavaScript sourcemap (.js.map) files. For example the calendar app. As far as I know, sourcemaps are not required in production, but to debug the JavaScript.
I did a little searching and found out, that my Nextcloud instance contains about 1500 JS sourcemap files which add up to about 1GB in total. That is a lot of stuff to ship if it is only needed for development. And these numbers increase if you count in the Nextcloud backups.
I wanted to ask if this is intentional behavior and if there is anything I am missing?
Maybe I did not find the right switch to turn the feature off or something like that?
I wrote a small thread about it, where you can see some numbers and folder structure.
There was an issue in 2023. I would be interested in @ChristophWurst opinion. I am not a developer.
On one of my Nextclouds JavaScript requires 83 MB of 87 MB for the app Calendar (95%). The js.map files in turn require about 60 MB of the 83 MB (72%). This means that js.map require about 69% of the total memory of Calendar. I donāt know whether this applies to all apps. Perhaps I have miscalculated.
My minimum Nextcloud needs about 600 MB. I donāt know how much of that is js.map. But I think thatās quite a lot. Unfortunately, memory is no longer being saved these days. People are simply buying larger systems. What a pity.
The browser doesnāt load those files unless needed for a stack trace. If anything, this will make our developerās life a lot harder if we can no longer read error traces.
That is correct, but ā¦
ā¦ it play a role in terms of download, installation, update, backup and restore e.g. on a Raspberry Pi with a weak internet connection, weak processor, weak hard drive or bad sd card. During the runtime, however, it is irrelevant for the Pi.
ā¦ conversely, you may also have to compare the memory consumption for the apps with the actual amount of data for user data, which is often in the GB or TB range for one Nextcloud, it is practically unnoticeable.
The .map files are only used if you debug with the browser inspector. In that case, queries are done from it to check wether there is a .map corresponding to the source file. The purpose is to have a āreadableā script for debugging purpose.So you can consider this is only anoying for the disk space (not the memory).
after installing nextcloud, or in a daily cron, you can launch this command:
Nobody created a mess. This is how our frontend stack and its tooling works.
I acknowledge that the additional storage requirement might seem like a waste to some people, but as we tried to explain, there is a reason for the files.
We prefer debuggability and maintenance over storage optimization in this case.
If 1GB of storage is an issue, you will likely not be able to do much with your Nextcloud.
For backup I can highly recommend a deduplicating solution. Have a look at borg, for example.
We cannot remove the source maps completely for the reasons described above. Itās not only for ādebugging by developersā purposes but also for bug reports.
āButton didnāt work, and there is an unexpected token on main.js:1:15436ā is pretty useless on a bug report.
However, there are many source maps kinds. Some have less size with fewer possibilities. It can be, e.g., ~60% smaller, losing some but not all debugging options.
We might discuss this possibility, weighing the limitations and the outcomes.
From a user and admin perspective Iād like to have a toggle that does the clean up whenever I install a new version. One that makes the tradeoff clear: smaller install size but harder to debug.
Re adding the map files in case of needed debug info is harder but maybe not impossible? I donāt know enough of update process and how integrity is maintained with plugins.
Your server only has 10GB of storage, or the Nextcloud instance is 10GB and with three backups you get a total of 40GB?
Either way, this isnāt big and certainly not enormous on average in 2025 when you can get a 1TB SSD for ~ā¬50. Of course, itās a different story if youāre using a web hosting service or a VPS, where storage is still expensive compared to local storage.
If by backups you mean the backups created by the Nextcloud updater, and you also have actual backups of your instance, you can delete them and do future updates with the --no-backup option to save some space.
From a user and admin perspective Iād like to have a toggle that does the clean up whenever I install a new version. One that makes the tradeoff clear: smaller install size but harder to debug.
This means that every installation/upgrade still downloads and unpacks all this data, which loses half of the purpose of removing/reducing the source maps.
If the only purpose is reducing the size on the disk afterward or in a backup - you can run a simple 1-line bash script after an upgrade or during backup.
Re adding the map files in case of needed debug info is harder but maybe not impossible? I donāt know enough of update process and how integrity is maintained with plugins.
In general, it is possible. Especially if there is a single enterprise installation with a specific infrastructure.
But we need something simple enough for the entire community. So that users could create bug reports with a simple copy/screenshot of the browser console. Without an advanced process of applying external source maps on production instance or setting up additional infrastructure components.
