feat: Use DIR_ASSETS path to locate resource bundles

[itsananderson]

Description of Change

Electron currently uses the DIR_MODULE constants DIR_EXE when querying the PathService to calculate resource paths, but the Chromium source and https://issues.chromium.org/issues/40203062 both discourage using these constants to locate assets, and instead recommend using DIR_ASSETS.

By default DIR_ASSETS is an alias for DIR_MODULE, but by updating Electron to use DIR_ASSETS, we align better with Chromium recommendations, and make it possible for apps with custom layouts to only need to override DIR_ASSETS.

In addition to changing the constants used internally for loading resources.pak and for the process.resourcesPath, this PR adds "assets" as a key that can be queried via app.getPath.

Because DIR_ASSETS is treated as an alias for DIR_MODULE by default, these changes should be a no-op for any existing apps.

Checklist

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

Release Notes

Notes: Internally switched to using DIR_ASSETS instead of DIR_MODULE/DIR_EXE to locate assets and resources, and added "assets" as a key that can be queried via app.getPath.

[itsananderson]

This is only tangentially related to the other changes, but libchromiumcontent hasn't existed for a long time, so it seemed worth updating these docs while I'm here.

[deepak1556]

This looks good, can you make the following additional changes

1. Use asset path for

   electron/shell/common/asar/archive_win.cc

   Lines 29 to 37 in d7ef8b7

   	base::FilePath exe_path;
   	if (!base::PathService::Get(base::FILE_EXE, &exe_path)) {
   	LOG(FATAL) << "Couldn't get exe file path";
   	}
   	base::FilePath relative_path;
   	if (!exe_path.DirName().AppendRelativePath(path_, &relative_path)) {
   	return std::nullopt;
   	}

2. Add a unit test that default app.getPath('assets') matches the path where the exe is located path.dirname(app.getPath('exe')) to confirm no-op of this change.

[itsananderson]

Add a unit test that default app.getPath('assets') matches the path where the exe is located path.dirname(app.getPath('exe')) to confirm no-op of this change.

@deepak1556 I started working on this but then got pulled into other work for awhile.

What I've found by adding some tests is that app.getPath('assets') on Mac returns Electron.app/Contents/Frameworks/Electron Framework.framework/Resources
rather than Electron.app/Contents/Resources. This might make it tricky to reconcile the Mac asset paths without breaking changes, because I believe Chromium looks for resources under Electron.app/Contents/Frameworks/Electron Framework.framework/Resources while Electron looks for resources under Electron.app/Contents/Resources. Fixing these to be consistent would probably require updates to Electron app packagers at the very least, but if any apps are hardcoding resource lookups, they could still be broken if we change resource locations.

[deepak1556]

Thanks for looking into the tests, if it would make things easier, we can expose the assets key to just windows and linux in this PR. MacOS can be follow-up if there is interest in changing asset dirs for this platform.

My initial comment for tests was also specific to windows and linux since the code paths touched in this PR are specific to those platforms.

[samuelmaddock]

API LGTM

[deepak1556]

Pending one more API approval @electron/wg-api

[codebytere]

API LGTM

[deepak1556]

Failing tests are unrelated, merging.

[release-clerk]

Release Notes Persisted

Internally switched to using DIR_ASSETS instead of DIR_MODULE/DIR_EXE to locate assets and resources, and added "assets" as a key that can be queried via app.getPath.

[trop]

I have automatically backported this PR to "38-x-y", please check out #47950

[trop]

I have automatically backported this PR to "37-x-y", please check out #47951