One goal of v1 of the new Sourcegraph VS Code extension is to provide a familiar experience for existing Sourcegraph users in their IDEs, which also makes the potential transition to using Sourcegraph.com easier for new users (acquired through the new VS Code extension). The easiest way to make that happen is to use the same components as the web application.
To that end, this PR introduces two new packages in order to share essential search code between client applications.
New Packages
search: General search types (e.g. QueryState. Can be used in any client context (e.g. web app, browser extension, CLIs).
search-ui: Search UI components that adhere to our branding. Can be used only in branded clients (e.g. web app, VS Code extension)
For reviewers
This PR is best reviewed by commit. I've done my best to make sure each commit is simple and that the code is in a working state. The overall diff is very misleading in terms of complexity; the vast majority of changes are updates to imports and stuff like making components accept PlatformContext in order to abstract GQL requests. The build is passing and search features check out in manual testing. However, we can split this into multiple PRs if that would increase confidence!
Changes
<SearchBox> (really all of web/src/search/input) to search-ui
Moves to to enable this:
CurrentAuthState query, export AuthenticatedUser type alias (does this belong in a separate auth package?)
web/src/keyboardShortcuts to shared/src/keyboardShortcuts
also needs isMacPlatform, lazyComponent, and observeResize from web/src/util to be moved to shared/src/util
web/src/search/useQueryIntelligence to search/src/useQueryIntelligence. This only depends on stuff already in shared (moving to search)
<MonacoEditor> from web/src/components to shared/src/components. This only depends on stuff already in shared (moving to search)
web/src/search/helpers.tsx to move to search, not search-ui
Settings schema type generation to move to shared (needed for quick links and <FilterLink>)
TemporarySettings to move to shared
Most of web/src/search/backend.tsx to search
SyntaxHighlightedSearchQuery to search-ui
<StreamingSearchResultsList> to search-ui. We could just move <StreamingSearchResults>, but that component is too intertwined with web stuff (e.g. code insights, search stack) so I think it makes more sense to pull out the list component and other shared components (like SearchAlert) and assemble an independent VSCE search results page. Additionally, <StreamingSearchResults> renders the search sidebar, whereas we want to render that in a VS Code sidebar webview.
Moves to enable this:
<ModalVideo> to search-ui
<ErrorAlert> to branded (maybe wildcard?)
<SearchResult> and <CommitSearchResultMatch> to search-ui
highlightCode from web/src/search/backend.tsx to search
Make web/src/user/settings/codeHosts/OrgUserNeedsCodeHost.tsx a render prop (depends on Apollo Client which will not be implemented for VSCE v1)
<NoResultsPage> to search-ui
Will have to pass in experimental features as prop instead of using useExperimentalFeatures (zustand store). Eventually we should think about how to more elegantly manage our zustand stores across clients
<AnnotatedSearchInput> to search-ui
<SearchSidebar> to search-ui as mentioned in the previous point.
Moves to to enable this:
This depends on the global useNavbarQueryState, so we should make a general SearchQueryState interface in search and pass the store instance as a prop.
<Revisions> sidebar section will stay in web until we get Apollo client working for VS Code webviews. Refactor <SearchSidebar> to accept getRevisions prop
<OnboardingTour> is web-only (for now?), so add a prefixContent prop for web consumers to render it into
Move client/web/src/search/helpers/queryExample.ts to search
Candidates for moves in future PRs
shared/src/search/query, shared/src/search/suggestions, and shared/src/search/stream.ts to search
