remove the ui/app and ui/lib folders

[brad-decker]

Problem statement

Giving instructions to new engineers (or even those who have been around the block) to go to the ui/app/components/app folder is somewhat confusing. This would be fine to just overcome, but it also provides no real value. In fact it disjoints the file structure by implying significance of ui/libs over things like ui/app/helpers and to further complicate the matter the ui/libs folder had test helpers in it (some were unused)

Solution

Relocate all files in ui/lib to the most sensible destination, for most this was ui/app/helpers/utils. Once done, flatten the contents of ui/app into ui/ making ui/ the top level folder of the entire frontend portion of the extension.

Also, 1316 files later, I'm sorry.

[metamaskbot]

Builds ready [e89996a]

• builds: chrome, firefox, opera
• bundle viz: background, ui, inpage, contentscript, ui-libs, bg-libs, phishing-detect
• build viz: Build System
• code coverage: Report
• storybook: Storybook
• all artifacts

Page Load Metrics (563 ± 43 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	45	71	57	8	4
		domContentLoaded	323	655	562	90	43
		load	325	656	563	90	43
		domInteractive	323	654	562	90	43

[metamaskbot]

Builds ready [4b5a49d]

• builds: chrome, firefox, opera
• bundle viz: background, ui, inpage, contentscript, ui-libs, bg-libs, phishing-detect
• build viz: Build System
• code coverage: Report
• storybook: Storybook
• all artifacts

Page Load Metrics (655 ± 60 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	51	89	63	11	5
		domContentLoaded	338	843	654	125	60
		load	339	845	655	125	60
		domInteractive	338	843	654	125	60

[darkwing]

Is there a way we can do this without losing all history 😬😬😬 ? Also, it might be good to separate the actual file moves into one commit and the config changes in another, so that rebases etc. aren't a horrible experience.

[brad-decker]

@darkwing I don't believe preserving history at the file level to be possible in all cases, but we will have the ability to see the file changes and connect the history manually. As an example the first entry for any "new" file in this PR will be the commit in this PR, which if clicked will inform the viewer of the old location. Browsing the repo at that point in history will give the rich file history while it was located in the previous place.

Not ideal, but unfortunately obscuring file history in this way isn't avoidable in many cases.

I did split out the configuration changes into a separate commit

[metamaskbot]

Builds ready [b85c8e6]

• builds: chrome, firefox, opera
• bundle viz: background, ui, inpage, contentscript, ui-libs, bg-libs, phishing-detect
• build viz: Build System
• code coverage: Report
• storybook: Storybook
• all artifacts

Page Load Metrics (694 ± 40 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	50	86	68	11	5
		domContentLoaded	455	787	693	83	40
		load	457	787	694	83	40
		domInteractive	455	786	693	83	40

[metamaskbot]

Builds ready [da07ac6]

• builds: chrome, firefox, opera
• bundle viz: background, ui, inpage, contentscript, ui-libs, bg-libs, phishing-detect
• build viz: Build System
• code coverage: Report
• storybook: Storybook
• all artifacts

Page Load Metrics (615 ± 31 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	46	70	60	8	4
		domContentLoaded	419	676	614	65	31
		load	420	677	615	65	31
		domInteractive	418	675	614	65	31

[brad-decker]

Waiting for the What's new feature to land before merging

[kumavis]

@brad-decker why do you think these are not being recognized as file renames?

[kumavis]

reading suggestions to prefer git mv when possible

[kumavis]

ohhh

git commit never detects renames. It just writes content to the repository. Renames (and copies as well) are only detected after the fact, i.e. when running git diff, git merge and friends. That's because git does not store any rename/copy information.

https://stackoverflow.com/questions/14832963/how-can-i-control-the-rename-threshold-when-committing-files-under-git

is that true? seems like git blame etc would have to re-run rename detection for every commit where the file was added
Edit: apparently it does

[brad-decker]

@kumavis Thanks for the lesson! I didn't know the entire interface is just being deciphered! I won't complain about github loading slowly on my huge PRs anymore lol.

[ryanml]

great work!