Automatic Type Acquisition needs some kind of garbage collection/cleanup, at least for old typescript versions?

[ariccio]

Suggestion

Automatic Type Acquisition automatically acquires necessary typescript types. That's great! The problem is that over the course of a few years of Typescript upgrades, my AppData/Local/Microsoft/Typescript folder had filled up with hundreds of thousands of files. This is actually a huge problem for several reasons:

• NTFS currently does NOT have a way to "clean up" old MFT entries. If the folder grows to contain more than a million or so files, your entire system will get permanently slower!
• It seems like Windows 10 likes to walk the whole AppData tree on login BEFORE even starting explorer, for me at least. It doesn't even do it in parallel (MSFT, please hire @ned14, lmao), so having hundreds of thousands of files to walk means I have to wait a whole lot longer to use my machine! If you have a bloated MFT, this gets even worse.

🔍 Search Terms

Automatic Type Acquisition

✅ Viability Checklist

My suggestion meets these guidelines:

• [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [X] This wouldn't change the runtime behavior of existing JavaScript code
• [X] This could be implemented without emitting different JS based on the types of the expressions
• [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [X] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Something to clean up the leftover type declarations from old versions of typescript. Or unused declarations. You could even use AgeStore!

📃 Motivating Example

Remove hundreds of thousands of files from dev machines! C'mon, wouldn't that be nice?

💻 Use Cases

The current approach seems to be to just let them accumulate forever. I just noticed this when running altWinDirStat (my old project, and working on it back in the day is also why my MFT is 3.5GB... trust me, a mechanical HDD with a 3.5GB MFT is insanely slow for everything), and trying to work around the slow login. I have just deleted several of the old TS folders, hoping to improve the situation without breaking anything. I haven't even checked if that broke anything before filing this bug.

[ned14]

@ariccio MSFT has no need to hire me, they have been very good and have fixed almost everything I have sent them to fix, even if it has sometimes taken them a few years to get it done. The Win32 enumeration API is now very very good, two orders of magnitude faster than it was. They added io_uring APIs to reduce socket i/o latencies. They fixed the IOCP scheduling bug with async file i/o introduced in mid Win 10. I really cannot fault them for fixing bugs.

MFT space reclamation is surely easy enough to implement if the drive is offline, however it probably would require a rewrite of the NTFS driver to make it work online, and from my friends in the Windows kernel team I know there would be zero appetite for that. Your alternative choices on Windows are very limited, ReFS can be used as a bootable drive but Windows is quite slow on it, and there are continuing long term stability issues with ReFS volumes. The best solution is to stop creating and deleting millions of files in a long lasting NTFS volume - if the files never change per release, I'd just mount an ISO image to a NTFS junction point, which Windows is perfectly capable of doing. Or loopback mount a sparse NTFS file as a NTFS junction point. There are lots of options here.

[ariccio]

Wait you mean they improved FindFirstFile? When did they do that?? How'd they do that? Is that win 11 only or something? I'm super excited to hear this!!

[ariccio]

(the reason I was creating millions of files is to stress test the directory tree visualization software I was working on, long before I suffered from the node_modules madness 😏🤣)

[ned14]

Wait you mean they improved FindFirstFile? When did they do that?? How'd they do that? Is that win 11 only or something? I'm super excited to hear this!!

Later Win10's definitely have a vastly improved implementation. It's now 99% of the NT kernel API performance when used directly. Still single threaded, obviously, but way way way better than it was on say Win7.

I can't be more precise, I only discovered it when a user reported they couldn't replicate my claims of LLFIO's directory enumeration being so much faster than the Win32 API. Turns out Microsoft fixed their stuff after I reported it. Good on them.