This is something I wanted to do for a long time. Would have best been before @marekweb starts (sorry!) but I sincerely believe this will make navigating the codebase much easier going forward. Here are the concrete issues solved by this:
File naming convention was snake_case, different from every other part of our TS code base (fixes #4372 (closed)).
The files named code_intelligence containing a lot of things not directly related to "code intelligence". These files are now named codeHost, because they define the codeHost object for each code host.
The libs folder was just a collection of code that wouldn't really match what one would consider "libraries". There was also shared/ and with no clear difference between the two. Instead, this is now sorted by the environment: browser-extension, native-integration and shared now also contains the former libs (code shared between the two). The folders inside libs that were code hosts implementations are now grouped in another folder code-hosts, which should make it easier to find the most important files.
Confusing location of code shared between code hosts: code_intelligence/code_intelligence.ts. This is now in code-hosts/shared.
Entry points were hard to find. E.g. the Phabricator native integration entry point (which is different from Bitbucket and Gitlab!) was nested somewhere deep in code_intelligence/phabricator. All entry points are now named .main.ts and in the top-level native-integration and browser-extension folders.
Ambiguous use of the term "extension" (is this a Sourcegraph extension or the browser extension?)
phabricator folder that only contained extensionHostFrame.html, which is not just used inside Phabricator. Moved to native-integration.
Top-level folder platform that doesn't fit into the top level in the hierarchy. It's now under shared/ because it's shared by native integrations and browser extension.
There are no logic changes here, only moves. Tested everything still builds & works.
If at all possible I'd like to avoid bike-shedding specific naming but just judge this PR by whether it is a net improvement (I strongly think so). Everything can still be changed in another PR
@marekweb since this would create merge conflicts for you if this gets merged I went ahead and rebased your branch as of eb396261b9383da3da05175458760094986cdd47 in branch refactor-fileinfo-renames-rebased and fixed the merge conflicts (you can set your branch to that with git reset --hard refactor-fileinfo-renames-rebased if you want after this is merged).
