feat: Clean cache command by d3xter666 · Pull Request #1394 · UI5/cli

d3xter666 · 2026-05-22T12:20:01Z

The command completely cleans the cache by removing the cache files as well as cleaning up the SQLite records.
It does not wipe out the SQLite DB file(s)

JIRA: CPOUI5FOUNDATION-891

Provide common interface for cache cleanup, but distribute the real cleanup among the respective destinations

RandomByte · 2026-06-01T14:50:42Z

@@ -0,0 +1,80 @@
+import path from "node:path";


It seems odd that this file is placed next to the other files responsible for managing the framework packages but doesn't use any of them. I would expect better integration here, e.g. no hardcoded assumptions like the framework/ directory name as well as checks for existing lockfiles to prevent deleting files while a download is running

I understand your point, but what botters me is that this might need a bit more of a refactoring.

Here's my rationale.

The AbstractInstaller is an abstract class that implements the lock logic. As the name suggests- it's an installer that is extended by the npm and maven installers.
Cache clanup, except from having in common the locks and paths, is a completelly different topic- it needs to clean the framework files. I have also seen that the framework folder is not configured in the AbstractInstaller, but is hardcoded in every installer.

The only clean option I forsee is to consolidate and reuse the locking logic and abstract the "framework" dir within the AbstractInstaller. Then somehow reuse this information in the cache cleaner.

I have refactored the code, so that framework folder is reused accross classes and the locking is respecte.
Hopefully, this change addresses you comment: 8a53eb8

Let me know if you have other concerns on that matter

Great. Just to bring this up: We now check that there is no active lock before deleting files but we do not set a lock during the deletion

Thanks! I have missed that! Now, should be fine: f6e0404

Great. One note though, I think there's a TOCTOU race condition between the check for existing locks and the creation of the cleanup lock. I.e.:

Installer A: passes cleanup-lock check (no cleanup lock yet) ✓

Cleaner B: passes hasActiveLocks (no per-package lock yet) ✓

Installer A: acquires its per-package lock, starts extracting into packages/...

Cleaner B: acquires cache-cleanup.lock, then fs.rms packages/ while A is writing → corrupted install, possibly ENOENT/EEXIST thrown to the user

You could change the order for the cleanup lock to first acquire the lock, then check for existing locks. If there are existing locks, release the cleanup lock immediately and start over (or something like that).

RandomByte · 2026-06-01T15:46:01Z

+ * @param {string} dirPath Absolute path to directory
+ * @returns {Promise<number>} Total size in bytes
+ */
+async function getDirectorySize(dirPath) {


On my system this results in a different number than du:

~/.ui5 ❯ du -sh framework 37G framework ❯ ui5 cache clean The following items from cache will be removed: • framework/ (31.9 GB) • buildCache/v0_7 (70.7 MB) Total: 32.0 GB

In my case, it also takes over a minute to calculate the size, which makes me wonder whether we should really do that or rather list the number of artifacts. Something like "this will delete 500 packages across 40 versions of UI5" would be much faster to calculate - not sure yet.

Hmmm, that's fair!
Thanks for that feedback! I have not tested with that hughe amount of data!
I suppose the data difference comes from the way we calculate the conversion from bytes -> mb -> gb -> etc.
We do it by dividing to 1024 while in some systems they use 1000. I'm not sure whetehr this is the case here.
Maybe, if we check the bytes we can say whether it's the calculation base, or something within the node's fs.stats and du.

Please take a look at my comment here: #1394 (comment)

With the current state:

❯ ui5 cache clean Checking cache at /Users/me/.ui5 … The following cached data will be removed: • UI5 Framework packages /Users/me/.ui5/framework (2043460 files) • Build cache (DB) /Users/me/.ui5/buildCache/v0_7 (70.7 MB) Do you want to continue? (y/N)

It still takes more than a minute to calculate this output. And I think the total size was still more meaningful than "two million files" (not even properly formatted). The alternative I mentioned before was to count not the files but the packages/versions.

I have revised and refactored this. Please, take a look here: #1394 (comment)

RandomByte · 2026-06-01T15:49:22Z

+export async function cleanCache(ui5DataDir) {
+	const frameworkDir = path.join(ui5DataDir, "framework");
+	try {
+		const size = await getDirectorySize(frameworkDir);


Since it takes a long time to calculate the size of a large cache, could we skip calculating it again during the cleaning?

Please take a look at my comment here: #1394 (comment)

I understand that the current implementation still counts the to-be-deleted files again, is that expected and can't be avoided?

The previous implementation used to count the bytes, now it counted files. But that turned to be a problematic too for big data sets. So, the solution will be just to do a dir traversal: X projects, Y libraries, Z versions.
It will be quick enough not to delay the execution.

Please, take a look at the rationale here: #1394 (comment)

matz3 · 2026-06-02T15:12:59Z

I think the usability of the command could be improved.

No information about the actual filesystem paths of the cache and relevant dirs (not in CLI description, not in --help, not in command output
No information about the relation to ui5DataDir config / UI5_DATA_DIR env var
No output when command is executed, and it might take a while to calculate the size, so users might assume the command is stuck if it does not print anything for a minute or longer.
Output lists two different sizes 197.0 MB vs 196.8 MB:

The following items from cache will be removed:
  • buildCache/v0_7 (197.0 MB)

Total: 197.0 MB


✓ Removed buildCache/v0_7 (196.8 MB)

Success: Cleaned 1 entry, freed 196.8 MB

(minor) Inconsistency in logged paths (framework/ vs framework):

The following items from cache will be removed:
  • framework/ (711.4 MB)

Total: 711.4 MB

Do you want to continue? (y/N) y

✓ Removed framework (711.4 MB)

d3xter666 · 2026-06-02T19:05:17Z

I have tried to improve the situation with the infmration for the execution of the cache clean command and have addressed all your concenrns.

Let me know if there's something more you'd expect.

Regarding the size report, there are some considerations we need to be aware of:

Getting framework cache dir size might require time. Even if you do that on your machine, it will take time. Even the du command on Mac uses cache in order to be quick, but the first run is not that fast. The optimal solution: Give information about the number of files that will be deleted
The purge of the DB cache is just the opposite! Selecting COUNT(*) of all rows might take significant amount of time to get the results. On the other hand, the size of the DB can be quite fast.

I have tried to somehow get advantage of these findings and provide the optimal solution- show metrics for what is fast and provide generic messages. Any other solutions will require certain compromises.

d3xter666 · 2026-06-09T13:08:33Z

Edit

Now the UX of this command is revised!

The real issue is enormous cache!

Collecting full information about what would be deleted is a haevy work and we simply cannot do it real time. In the end, for the end user it's important what would be deleted!
Given that, my proposal would be a summary information that does not need to collect all the files or their sizes. Instead, just put an overview:

Confirmation

Checking cache at /my/data/dir/.ui5 …

The following cached data will be removed:

  • UI5 Framework packages   /my/data/dir/.ui5/framework   (1 project, 18 libraries, 212 versions)
  • Build cache (DB)         /my/data/dir/.ui5/buildCache/v0_7   (100.0 KB)

Do you want to continue? (y/N)

During cache cleanup

If we now decide to accept purging of the hughe cache, it will take some time cleaning it up. We cannot do anythinbg about it, but simply wait for the fuiles to be deleted.
For that purpose, I have created an real time "monitor" of what is being deleted:

 ⠏ UI5 Framework packages   …/sap.m/1.52.14/src/sap/m/BarRenderer.js   2.86 s

Final summary

✓ Removed UI5 Framework packages   (/my/data/dir/.ui5/framework · 1 project, 18 libraries, 212 versions)
✓ Removed Build cache (DB)   (/my/data/dir/.ui5/buildCache/v0_7 · 100.0 MB)

Success: Cleaned UI5 Framework packages and Build cache (DB)

Hopefully, this is good enough as UX and fast enough, so that developers get feedback what is actually happenning

RandomByte · 2026-06-09T13:41:48Z

That's better. On my system it's very fast now:

Checking cache at /Users/me/.ui5 …

The following cached data will be removed:

  • UI5 Framework packages   /Users/me/.ui5/framework   (2 projects, 155 libraries, 1189 versions)
  • Build cache (DB)         /Users/me/.ui5/buildCache/v0_7   (70.7 MB)

Do you want to continue? (y/N)

But I think the term projects is misleading here. Usually every UI5 app or library is a project. I would drop that entirely and rather say 1.189 versions of 155 libraries (ideally with a decimal separator?)

I don't really think we need a progress indicator for the deletion process. It is expected to take a while, I would rather not add code just for that.

d3xter666 requested a review from a team May 22, 2026 12:22

d3xter666 force-pushed the feat-clean-cache branch 2 times, most recently from 83f2262 to d52c4ad Compare May 26, 2026 06:29

RandomByte force-pushed the feat/incremental-build-4 branch from 7c59782 to 444977d Compare May 27, 2026 15:40

matz3 reviewed May 28, 2026

View reviewed changes

Comment thread packages/project/lib/cache/CacheCleanup.js Outdated

Comment thread packages/project/lib/cache/CacheCleanup.js Outdated

Comment thread packages/project/lib/cache/CacheCleanup.js Outdated

Comment thread packages/cli/lib/cli/commands/cache.js

RandomByte force-pushed the feat/incremental-build-4 branch from c2dc7b8 to 1041695 Compare May 29, 2026 08:11

d3xter666 force-pushed the feat-clean-cache branch 2 times, most recently from dc31834 to f5def12 Compare May 29, 2026 08:29

RandomByte force-pushed the feat/incremental-build-4 branch from 1041695 to 66296d5 Compare May 29, 2026 08:49

d3xter666 force-pushed the feat-clean-cache branch 2 times, most recently from 77f7320 to aa280da Compare May 29, 2026 10:27

matz3 reviewed May 29, 2026

View reviewed changes

Comment thread packages/project/lib/build/cache/CacheCleanup.js Outdated

d3xter666 force-pushed the feat-clean-cache branch from 34fd55f to 7473bd4 Compare May 29, 2026 13:02

d3xter666 requested a review from matz3 May 29, 2026 13:21

d3xter666 force-pushed the feat-clean-cache branch 2 times, most recently from 7b17cc0 to 569ff71 Compare May 29, 2026 15:44

d3xter666 requested a review from a team June 1, 2026 07:46

d3xter666 changed the base branch from feat/incremental-build-4 to main June 1, 2026 10:10

d3xter666 added 11 commits June 1, 2026 13:19

feat: Clean cache command

9bcacaf

refactor: Use single place for DB manipulation

d49b45d

refactor: Simplify cache clean

c64092a

refactor: Position correctly the CacheCleanup

30df6b5

refactor: Add confirmation dialog for the cache clean command

7318ffe

refactor: Rename cacheVersionDir

0320c6f

refactor: Restore location of CacheCleanup

b0c9252

fix: Clean only current cache version

dc168dc

refactor: Simplify CacheCleanup

becc3a8

test: Improve coverage

c958891

refactor: CLI package orchestrates cache cleanup

36fd376

Provide common interface for cache cleanup, but distribute the real cleanup among the respective destinations

d3xter666 force-pushed the feat-clean-cache branch from 569ff71 to 36fd376 Compare June 1, 2026 10:22

d3xter666 added 2 commits June 1, 2026 13:44

refactor: Add skip confirmation option

c1eb38c

fix: Windows paths for tests

48aafe9

RandomByte reviewed Jun 1, 2026

View reviewed changes

Comment thread packages/project/lib/build/cache/CacheManager.js

d3xter666 added 4 commits June 2, 2026 11:59

refactor: Use yesno package for CLI confirmation

1c161bb

refactor: Simplify cleanup meta structure

2631451

fix: Add guard to not accidently create a new DB

1ade6fd

refactor: Reuse meta from installers in cache cleanup

8a53eb8

d3xter666 added 3 commits June 2, 2026 18:54

refactor: Cleanup details

fd604cd

fix: Respect datadir config

9c81ede

docs: Update cache clean --help CLI information

8172c6f

d3xter666 requested review from a team and RandomByte June 2, 2026 19:06

d3xter666 added 2 commits June 9, 2026 14:24

refactor: Cleanup confirmation revised

e45d5ff

refactor: Revise actual cleanup UX

d5e28f2

d3xter666 added 2 commits June 9, 2026 16:11

fix: Docs generation failure

2ed5504

fix: Respect cleanup locking

f6e0404

refactor: Redundant cleanup summary

ac95e46

Conversation

d3xter666 commented May 22, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d3xter666 Jun 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d3xter666 Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

matz3 commented Jun 2, 2026

Uh oh!

d3xter666 commented Jun 2, 2026

Uh oh!

d3xter666 commented Jun 9, 2026

Edit

Confirmation

During cache cleanup

Final summary

Uh oh!

RandomByte commented Jun 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

d3xter666 Jun 2, 2026 •

edited

Loading

d3xter666 Jun 9, 2026 •

edited

Loading