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_intelligence
containing a lot of things not directly related to "code intelligence". These files are now namedcodeHost
, because they define thecodeHost
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 alsoshared/
and with no clear difference between the two. Instead, this is now sorted by the environment:browser-extension
,native-integration
andshared
now also contains the formerlibs
(code shared between the two). The folders insidelibs
that 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.ts
and in the top-levelnative-integration
andbrowser-extension
folders. - Ambiguous use of the term "extension" (is this a Sourcegraph extension or the browser extension?)
-
phabricator
folder that only containedextensionHostFrame.html
, which is not just used inside Phabricator. Moved tonative-integration
. - Top-level folder
platform
that 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).