Rename browser extension files and folders
Created by: felixfbecker
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_intelligencecontaining a lot of things not directly related to "code intelligence". These files are now namedcodeHost, because they define thecodeHostobject for each code host. - The
libsfolder was just a collection of code that wouldn't really match what one would consider "libraries". There was alsoshared/and with no clear difference between the two. Instead, this is now sorted by the environment:browser-extension,native-integrationandsharednow also contains the formerlibs(code shared between the two). The folders insidelibsthat were code hosts implementations are now grouped in another foldercode-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 incode-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.tsand in the top-levelnative-integrationandbrowser-extensionfolders. - Ambiguous use of the term "extension" (is this a Sourcegraph extension or the browser extension?)
-
phabricatorfolder that only containedextensionHostFrame.html, which is not just used inside Phabricator. Moved tonative-integration. - Top-level folder
platformthat doesn't fit into the top level in the hierarchy. It's now undershared/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).