brave_resources.pak should be not differ on each build or platform architecture

[petemill]

Description

Mac Arm and Intel builds are generating different brave_resources.pak resource files. This results in an error when creating a Universal app for distribution. To get around this error, we have been copying one platform's brave_resources.pak over the other. This can result in catastrophic runtime errors.

The priority is to make sure filenames are the same, then the catastrophic errors will be removed.

The secondary goal is to make sure that brave_resources.pak is identical every time it's generated. Then we will be able to keep the file as part of the Universal app creation and will receive a build-time error if they are different.

Items preventing this from occuring:

• Webpack references from different architectures' output directories (e.g. Release and Release_arm64) creates different output file names. File names are based on a generated hash / ID of all the paths. This can be observed by comparing file names in e.g. gen/brave/components/web-ui-brave_new_tab/.
• Webpack file content also differs from different architectures' output directories since when concatenating modules, the module paths and its dependencies paths are used to generate the module ID which is used as a reference to "require" the concatenated module. This can be observed by comparing file contents in e.g. gen/brave/components/web-ui-brave_new_tab/.
• WDP builds occur in a different temp directory each time. This temp directory path is used to create the chunk file name and the concatenated module IDs. WDP uses the broccoli build system. This can be observed by comparing file contents in gen/brave/web-discovery-project.

Some helpful commands I've used to assess results after changing webpack configuration:

Compile the NTP using Webpack at both ./out/Release and ./out/Release_arm64 paths

Create a symlink to pretend there's another build config

cd src/out
ln-s ./Release_arm64 ./Release

Build NTP for ./Release

cd Release

python3 ../../brave/script/transpile-web-ui.py --output_path=/Users/petemill/Downloads/tmp/intel --root_gen_dir=$(pwd)/gen --grd_name=brave_new_tab.grd --resource_name=brave_new_tab --depfile_path=$(pwd)/gen/brave/components/brave_new_tab_ui/brave_new_tab_ui.d --webpack_alias=chromeapp --entry=brave_new_tab=/Users/petemill/Development/Brave/brave-browser/src/brave/components/brave_new_tab_ui/brave_new_tab.tsx --production

cd ../Release_arm64

python3 ../../brave/script/transpile-web-ui.py --output_path=/Users/petemill/Downloads/tmp/arm --root_gen_dir=$(pwd)/gen --grd_name=brave_new_tab.grd --resource_name=brave_new_tab --depfile_path=$(pwd)/gen/brave/components/brave_new_tab_ui/brave_new_tab_ui.d --webpack_alias=chromeapp --entry=brave_new_tab=/Users/petemill/Development/Brave/brave-browser/src/brave/components/brave_new_tab_ui/brave_new_tab.tsx --production

Compare the output

cd ~/Downloads/tmp
opendiff ./arm ./intel

Compare the real brave_resources.pak file from actual intel and arm builds

# First do a Release build on each machine
# Then have the intel machine accessible from the arm machine (mine is at /Volumes/petemill)
# pak_util.py doesn't currently work with brave patches, so I'm using a different chromium dir to find that util

cd ~/Downloads/tmp/pak-compare

rm -rf arm && mkdir arm && cd arm && ~/Development/Brave/brave-browser-chromium-upgrade/src/tools/grit/pak_util.py extract "/Users/petemill/Development/Brave/brave-browser/src/out/Release_arm64/Brave Browser.app/Contents/Frameworks/Brave Browser Framework.framework/Versions/125.1.68.0/Resources/brave_resources.pak" && cd ..

rm -rf intel && mkdir intel && cd intel && ~/Development/Brave/brave-browser-chromium-upgrade/src/tools/grit/pak_util.py extract "/Volumes/petemill/Development/Brave/brave-browser/src/out/Release/Brave Browser.app/Contents/Frameworks/Brave Browser Framework.framework/Versions/125.1.68.0/Resources/brave_resources.pak" && cd ..

opendiff ./arm ./intel

[fallaciousreasoning]

Once we've fixed this, I wonder if we should add a step that verifies these two pak files are the same - if they aren't its potentially catastrophic