feat: Redirect Electron/Chromium cache location

[emmkimme]

************ DRAFT ***********

Description of Change

This MR fixes or help on the following issues:

• Customize Electron/Chromium cache location #18309.
• AppData folder has large cache which affects "roaming profile" users desktop/desktop#6523.
• Cache directory on windows should be %localappdata% by default #1404.

Notes: This is a new version of feat: Custom cache path

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

What is managed the cache is a bit complicated to define.

As a matter of rules, what is in the cache is:

• beyond our control in term of creation / modification and storage format
• if erased does not prevent the application to start
• if erased is automatically rebuilt from scratch with 'known' side effects (potentially have to re-enter credentials and re-fill forms, performance of a cold start, ...)

Additional notes

This change is backward compatible.
For concurrent access violation, the cache folder must not be shared by different users.
For performance purpose, it must be set on a fast drive.

[MarshallOfSound]

if erased is automatically rebuilt from scratch with 'known' side effects (potentially have to re-enter credentials and re-fill forms, performance of a cold start, ...)

This may be expected for your perspective but for others this is an unacceptable breaking change to Electron that updating will result in cached data ceasing to exist.

This issue hasn't been fixed because no one has implemented a nice way of handling this that doesn't cause data loss.

[anatoli26]

if erased is automatically rebuilt from scratch with 'known' side effects (potentially have to re-enter credentials and re-fill forms, performance of a cold start, ...)

This may be expected for your perspective but for others this is an unacceptable breaking change to Electron that updating will result in cached data ceasing to exist.

This issue hasn't been fixed because no one has implemented a nice way of handling this that doesn't cause data loss.

It was already discussed at length in #8124, in particular: #8124 (comment).

What is needed in electron is to provide to the electron-based app developers the possibility to define the 3 paths and by default assign them the currently used values, so no functional change results from the code change.

Then each electron-based app dev team decides how to best proceed with the newly available options in their apps.

[emmkimme]

Guess, there is some misunderstood, I did not break anything in term of functionality, I just offer a way to redirect the 'cache' to another location, there is no loss of data and the backward compatibility is preserved.
@anatoli26 Thanks for the reference to the discussion, I will have a look.

[zcbenz]

Can you add a note that it defaults to userData?

[zcbenz]

The cache does not interfere with paths set by app.setPath, it is mostly about the path providers, which we do not expose any JavaScript in Electron, so I think we can remove this InvalidateCache call.

[aairey]

@emmkimme could you have another look at this, please?

[emmkimme]

@emmkimme could you have another look at this, please?

Yes, will manage early next year, have a good end of year.

[reitzig]

What is needed in electron is to provide to the electron-based app developers the possibility to define the 3 paths and by default assign them the currently used values, so no functional change results from the code change.

No, we need a "breaking" change! (Quotes because cache location shouldn't matter at all to the app.) A transitionary period would be easy to implement, although more work than just changing the paths to something appropriate.

Then each electron-based app dev team decides how to best proceed with the newly available options in their apps.

So we get a non-standardized mess instead of a bad standard? If they change it at all? No, thanks. Electron needs a fix, not the apps.

[emmkimme]

What is needed in electron is to provide to the electron-based app developers the possibility to define the 3 paths and by default assign them the currently used values, so no functional change results from the code change.

No, we need a "breaking" change! (Quotes because cache location shouldn't matter at all to the app.) A transitionary period would be easy to implement, although more work than just changing the paths to something appropriate.

Then each electron-based app dev team decides how to best proceed with the newly available options in their apps.

So we get a non-standardized mess instead of a bad standard? If they change it at all? No, thanks. Electron needs a fix, not the apps.

To be fair, we are a bit lost. It seems to have a long discussion/context feed by experts on this area, and clearly, we are not and do not even pretend to be.

We implemented this solution in our own Electron 4 years ago and it resolves the concerns of our customer which are on Citrix, VDI,... (see issues mentioned).

We had the naive feeling it could help other people facing the same problem and as good citizen, we would like to contribute.
This is our 3rd revised MR because code changed so often these past years.

If the general feedback is, this MR does not help at all, it is not even a first step to the right direction, too specific, raise more issues than the ones solved,... so it does not make sense to keep going. We will wait for a better contribution from the Electron community, hope it will
come soon and then be able use an Electron without patching it. Thanks for your comments.

[miniak]

@emmkimme are you still planning to work on this PR?

[emmkimme]

The solution works fine on my side for more than 3 years and deployed with our product on hundreds of thousands users (Mac, Linux, Windows) without any issues. It fixes 5 and 7 years old issues which prevents Electron to manage properly Virtual Env.
To be fair, I'm tired to fight for this MR (more than 4 Years !), people always pointed me to a never ending thread #8124 started in 2016, and still nothing !,
In all innocence, I thought this MR was a good first step to a better solution, seems definitely not.
So I give up and I hope, one day, a solution will be finally implemented, for those that are not in position to compile their own versions of Electron.

[zcbenz]

I'm continuing the work of this PR in #33554.