Library folder in project files needs restructure. It is too large. New HDRP 11 project has 856MB which takes a while when project is loading and when reading and pulling files.
Library should be on 10th scale smaller then is now.
Unity editor should be rescaled back to 2018.4LTS size of 2.7GB.
Do you have the Library folder under version control?
https://docs.unity3d.com/Manual/ExternalVersionControlSystemSupport.html
Agree that these library folders are huge, I need to shuffle around on my drive right now already as I typically have two copies of the project on (one on stable release, one on newest beta to evaluate new features).
One single library folder is by now:
wow.
No, I don’t have it.
what is the directory size breakdown if you use windirstat? curious to see what else is contributing other than hdrp (or dirs within hdrp)
Assets, Logs, Packages, Projects Settings, User settings all together is 261 kB (kilobytes)
I checked in folder properties.
Yeah this is one of the things that has always irked me about Unity. How can the Library folder be so massive? Most of the time (Especially when using DOTS) 95% of the space is taken up by the PackageCache. which leads me to think, why doesn’t Unity just Symlink the packages? Instead of copying them all over. Especially if you have a ton of different projects, the package cache gets copied n-times per project and depending on how many packages you have installed in your project! 
(DOTS IS THE WORST OFFENDER OF THIS)
Hopefully Unity is taking a serious look into lowering the sizes of the projects because man does it make using other engines like Godot really enticing… 
Damn!! That’s actually insane! You must be working on a pretty big project!
You’d be surprised how likely it is for files inside a symlink dir to not get recognized at all by Unity. There is an inconsistent case in one of my projects where some assets just don’t appear when you do AssetDatabase.FindAssets because the folder is symlinked to 3 other locations. So you have to manually scrape the directory using System.IO
And yeah I agree, smaller project sized would be really nice to have, there was one that I used to work with that had a lib folder be 40gb in size.
Mostly because of Windows. On Windows, creating symlinks is a painful experience.
Not to mention going through symlinks in case of a high performance IO application like Unity is slow. Maybe loading your couple of Gb project is okay, but when you hit the tens or hundreds of Gigabytes…
And file operations (creating projects, installing packages, code compilation, etc) are slow and generally have a lot of complaints about them already.
For further reading:
https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/
also: https://docs.microsoft.com/en-us/windows/apps/get-started/enable-your-device-for-development
Oh, and because the storage is already super-cheap. Buy a bigger SSD, it is affordable if you want to make games and you take it seriously.
Just switched from 2020.1 to 2020.2 and deleted my library up-front. Quite some interesting changes:
By stating “just switched” I meant waiting for 16 hours 
Courtesy of…
Barely-threaded asset import!
Wasting time since 2005!
Actually, I had the task manager open most of the time, nearly 100% all the way through. There seems to be some crazy work going on. Especially for tif and tga files.
Must be that some importers are multi-threaded, but the process itself isn’t, so you still can’t import multiple assets at once if there are free threads. I see on average 2.something (and rarely 4.something) threads (out of 8), at use during the process.
3D asset import is done one at a time on a 16 cores machine. Why? Why not.
I was referring to Unity Symlinking the PackageCache folder only which usually tend to take up a lot of space relative to a smaller project (~1-2gb if using DOTS otherwise ~400mb). Symlinking on windows is super easy, unless you are not an admin. Which would be surprising if people using Unity were not the admins of their own computer 
. But If Unity created the symlinks then the user wouldn’t have to worry about the annoying privileges. OR if symlinks are really impossible, (which I don’t think they are) then why not have all unity projects reference the global packages folder in AppData\Local\Unity\cache\packages instead of copying over the folders one by one? Saves time importing packages and saves disk space! Win win!
Also also the idea of “Just buy a bigger storage drive” is the reason why programs around the world keep getting more and more bloated. It feels like the quality of programs keep dropping and people are fine with it because they can just buy more storage or buy a faster CPU if the program is unoptimized
I wouldn’t bet on it. Using the global cache, as you propose, is the best solution.
Oh boy. I’d attribute a lot of that to the lack of runtime package management, and instead copying all dependencies to the build. It seems that the current trend is crappy web-based apps (Electron) that use way too much RAM to render simple GUIs, CEF being >100 MB, I think. What happened to redistributables, like .NET Framework?
I feel your pain. It’s ridiculous.
Now, bear in mind that Library folder can (and will) keep old/irrelevant files after an engine upgrade or package upgrade. Deleting and regenerating the Library usually frees up some space. (Which is not an aceptable solution ofc, but might be worth as a little band aid to do over night).