What: This PR does the bare minimum to migrate the current community
search pages to Svelte. A better strategy for managing them is needed in
the medium/long term.
How: The community pages live at the root (e.g. `/kubernetes`) which
complicates things, but I'll get to that later. The page is implemented
as a single parameterized route. A parameter matcher is used to validate
the community name. Because these pages should only be accessible on
dotcom the matcher also validates whether or not we are on dotcom (if
not, the path will be matched against a different route).
The page config is stored in a separate module so that it's no included
in every page and so that it can be used in the integration test.
The loader and page implementation themselves are straightforward. I
made a couple of changes in other modules to make implementation easier:
- Extracted the parameter type of the `marked` function so that it can
be used as prop type.
- Added an `inline` option to `marked` that allows formatting markdown
as 'inline', i.e. without `p` wrapper.
- Added a `wrap` prop to `SyntaxHighlightedQuery.svelte` to configure
line wrapping of syntax highlighted search queries (instead of having to
overwrite styles with `:global`).
- Extended the route code generator to be able to handle single
parameter segments and the `communitySearchContext` matcher.
Because the community routes should only be available on dotcom I added
a new tag to the code generator that allows it include routes only for
dotcom.
Once we change how all this works and have community search pages live
under a different path we can simplify this again.
Result:
| React | Svelte |
|--------|--------|
|
|
|
## Test plan
- New integration tests.
- Verified that `/kubernetes` shows a 'repo not found error' when
running against S2.
- Verified that `/kubernetes` shows the community page when running
against dotcom.
- Verified that `window.context.svelteKit.enabledRoutes` contains the
community page route in enterprise mode but not in dotcom mode.
This adds support for navigating between search results with keyboard
shortcuts. Similar to the React app, `j` or `down` means "next result",
and `k` or `up` means previous results. To accompany this change, when a
search is submitted, the first result is focused by default to
facilitate iterating over results with the keyboard.
The first version of the file tree for the revision panel had flat file
names. This meant that files were not organized, they were very
horizontal-space-sensitive, and you could not filter to a directory
(only repo and file name).
This updates the file filter to be a full tree, which I find much easier
to use.
closes:
https://linear.app/sourcegraph/issue/SRCH-622/remove-old-cody-web-entirely
Removes the old Cody Web completely.
## Test plan
- sg start
- visit /cody/chat and you should see the new unified panel Cody Web
without having to turn on any feature flags.
- check the blob view sidebar for the same.
## Changelog
- The new Cody Web is enabled by default and the older version of Cody
Web is completely removed from both standalone chat and sidebar.
Sourcegraph's GitHub discussions have been defunct for awhile, but links
to them persisted in READMEs and documentation.
## Test plan
Documentation update only.
Fixes srch-867
This commit adds a new command, `web-sveltekit-prod`, which simplies
builds the SvelteKit app and exits.
This command is now run by default when using `sg start`, so the assets
will be available locally.
Note however that the build process is quite slow, which is why I didn't
make it rebuild on file changes. Using the vite dev server, e.g. via `sg
start enterprise-sveltekit`, delivers a much better experience.
To make the integration a bit more ergonomic, I made additional changes:
- When run via `sg` (determined by checking `DEPLOY_TYPE`) compiler
warnings are not printed. That reduces noise in the `sg` output.
- I made similar changes to the svelte check bazel target to make it
easier to spot actuall errors (warnings are still important to fix but
since they don't cause the target to fail they just make it difficult to
spot the actual error).
- Since I finally found out about the `onwarn` handler, I made it so
that warnings about missing declarations are ignored. These warnings
occur for every icon because the Svelte compiler doesn't respect ambient
d.ts files.
- And since I made icon warning related changes I also documented a bit
how icons work in the app.
## Test plan
- `sg start` runs the `web-sveltekit-prod` command and the Svelte app is
served when going to `https://sourcegraph.test:3443/search`.
- The output of `bazel test //client/web-sveltekit:svelte-check` now
only contains errors.
- The output of `pnpm dev` (vite devserver) shows warnings that are not
related to icons.
Fixes srch-859
Problem: Currently the sidebar can reopen in the following scenario:
- Go to search home and submit a search
- On the search results page click the menu icon to open the sidebar and
click 'Code Search' to go back to search home.
- Execute a different query
- -> this brings you back to search results but with the menu sidebar
open
Looking at the code it's understandable that this happens: We never
close the sidebar. But this problem wasn't very visible because every
entry in the nav sidebar either brings you to the React app or to a page
with inline nav menu.
So this commit fixes the issue by closing the sidebar whenever we
navigate to a different page.
## Test plan
Manual testing. I added a temporary nav entry that would bring me to the
sourcegraph repo page. Clicking on it from the search results page
caused the sidebar to close.
Fixes srch-858
Currently the menu icon rotates when hovering over it. The animation
should only target the Sourcegraph logo.
Additional changes:
- Move icon color style prop into CSS declaration (avoids inserting an
additional element)
- Let the animation target the link instead of the icon. There doesn't
seem to be reason why we actually need to target the `svg` element via
`:global`.
## Test plan
Manual testing.
There currently isn't a 'one step' way to start a local Sourcegraph
instance with the SvelteKit app.
This commit adds `sg start enterprise-sveltekit` to fix that.
The changes in https://github.com/sourcegraph/sourcegraph/pull/64272
allow us to run the vite dev server in front of the Sourcegraph
instance, instead of building the assets and having them served by
frontend.
This gives us the benefit of hot module reloading and in general seems
to be a less fragile approach.
It's basically the same what we do with the React app in development
mode.
## Test plan
`sg start enterprise-sveltekit` starts the vite dev server as well as
the sourcegraph instance. Navigating to
`https://sourcegraph.test:3443/search` opens the Svelte app (when
enabled and logged in). Making a change in a source file updates the web
page immediately.
`sg start web-sveltekit-standalone` still works
I don't know why but having `overflow-x` causes the content of the
hovercard to not fully expand to the edges. It has something to do with
the sizing of the `hr` element.
## Test plan
Manual testing.
This commit adds the necessary logic to open the explorer tab for
multiple references and for implementations. I basically copied what
@camdencheek did for the references tab.
## Test plan
Hover over `adapt` in
http://localhost:5173/github.com/sveltejs/kit@65931f276ac2102032e3032c864a472eee19b7bb/-/blob/packages/kit/src/exports/vite/index.js?L890
and click 'got to definition'. The explore panel with should open with
the definitions tab selected.
I wasn't able to test the find implementations logic because I don't
know for which language we have this implemented.
The screenshot images for the welcome overlay (both in Svelte and React)
are quite large.
In Svelte specifically, because they are implemented as Svelte
components, this adds a lot of code to the root layout and makes the
bundle quite large.
This commit converts the Svelte components to image files and passes
them (and the React ones) through [svgo](https://github.com/svg/svgo).
On one hand that makes the images much smaller, on the other hand in
Svelte the images are now independent of the JS code and can be loaded
separately (the React app was already using an `img` element).
Before svgo:
```
$ ls src/lib/assets/
total 3.1M
5.1K Aug 7 18:45 sourcegraph-logo.svg
1.5M Aug 7 18:46 welcome-screenshot-dark.svg
1.6M Aug 7 18:46 welcome-screenshot-light.svg
```
After svgo:
```
$ ls src/lib/assets/
total 1.4M
5.1K Aug 7 18:45 sourcegraph-logo.svg
667K Aug 7 18:50 welcome-screenshot-dark.svg
667K Aug 7 18:50 welcome-screenshot-light.svg
```
## Test plan
I temporarily changed the code so that the welcome dialog is always
shown in the Svelte app and inspected the image. It still seems to look
the same.
This makes some requested changes to the welcome banner.
Notably:
- We no longer show the dialog unless the user switches into the svelte
version from react
- We don't show the dialog on every switch
- The dialog is accessible in the React via the "Learn more" button in
the menu
- Copy is updated to be less verbose
- The request for feedback is only shown once when switching out of the
svelte webapp
Fixes srch-851
A consequence of https://github.com/sourcegraph/sourcegraph/pull/64272
is that redirecting to the cody marketing page on dotcom didn't work.
That's because `/cody` is not provided by the server as a known page.
A simple fix would be to mark the link as external, but we'd have to
keep in mind to do this in all places (present and future).
A more "central" fix is to add this page to a hardcoded list of known
pages that are not provided by the server.
## Test plan
Manual testing
Currently the link element doesn't extend to the full width of the
sidebar. You can click outside of the actual text to navigate to the
file, but it won't be preloaded.
Now the link occupies the full width.
## Test plan
Manual testing.
Closes srch-838
This commit extends the search progress popover and adds the search jobs
section.
In the React version the UI for the popover differs slightly when search
jobs are enabled vs not enabled.
I decided to ignore the differences and only impolemented the style used
for the 'search jobs enabled' version, which makes the popover a bit
more compact.
The logic for validating and creating a search job is encapsulated in a
class which makes it easy to conditionally show the search jobs UI.
Additional changes:
- Skipped items is now a list and uses `<details>` elements which is
semantically more correct. We loose the styling of the chevron but I
think that's OK.
- LoadingSpinner was updated to work inline.
- Logging was fixed (?) in the React version to send the correct
meta-data.
- Added integration tests for the search job popover behavior
## Test plan
Integration tests and manual testing.
I noticed that non-svelte repo subpages haven't been redirected to the
React app in local development (it works as expected in production).
That's because the proxy doesn't know about them since they are not part
of `knownRoutes`.
We could update the server code to include those routes as well but that
seems heavey handed just to make local development work.
I think in this case it's fine to have manual entries for the handful of
repo subpages that have not been migrated to Svelte yet.
## Test plan
Manual testing.
tl;dr: Everything is derived from `window.context.svelteKit.knownRoutes`
*buckle up*
### Context
After the new web app was enabled by default on dotcom I looked at
dotcom data in Sentry to see if there was anything out of the ordinary.
I noticed a high number of errors related to resolving repository
information. The most common non-existing repository that was reported
was `-/sign-out`.
Of course this shouldn't happen. `/-/sign-out` is the sign out URL and
shouldn't be interpreted as a repository.
Currently we prevent SvelteKit from interpreting specific paths as
repositories by using the `reporev` parameter validator:
```ts
// src/params/reporev.ts
const topLevelPaths = [
'insights',
'search-jobs',
'saved-searches',
// ... many more here
]
const topLevelPathRegex = new RegExp(`^(${topLevelPaths.join('|')})($|/)`)
// This ensures that we never consider paths containing /-/ and pointing
// to non-existing pages as repo name
export const match: ParamMatcher = param => {
// Note: param doesn't have a leading slash
return !topLevelPathRegex.test(param) && !param.includes('/-/')
}
```
`-/sign-out` was not in that list, including others which have been
added since this file was originally created.
Adding it would have been the simple solution but having to maintain
this list manually has always irked me. Now we have a better way...
### Production changes
#### Client side
It turns out we are already sending a list of known routes to the client
in `window.context.svelteKit.knownRoutes` to basically do the same
thing: test whether a given path is a page or a repository.
```ts
// src/lib/navigation.ts
let knownRoutesRegex: RegExp | undefined
function getKnownRoutesRegex(): RegExp {
if (!knownRoutesRegex) {
knownRoutesRegex = new RegExp(`(${window.context?.svelteKit?.knownRoutes?.join(')|(')})`)
}
return knownRoutesRegex
}
// ...
export function isRouteEnabled(pathname: string): boolean {
let foundRoute: SvelteKitRoute | undefined
// [...]
if (foundRoute) {
if (foundRoute.isRepoRoot) {
// Check known routes to see if there is a more specific route than the repo root.
// If yes then we should load the React app (if the more specific route was enabled
// it would have been found above).
return !getKnownRoutesRegex().test(pathname)
}
return true
}
return false
}
```
Why do we have the `reporev` validator and `isRouteEnabled`? They
basically do the same thing (check whether a path is a known page or a
repository) the first (`reporev`) is used by SvelteKit to determine
which route a path corresponds to (i.e. to navigate to the repository
page or whether the page doesn't exist) and the second one
(`isRouteEnabled`) is used after the route resolution but before route
loading. It's used to trigger a full page refresh to fetch the React
version if necessary.
Anyways, since we already have a list of known pages from the server,
the parameter validator should just use it too. Except it didn't work,
which made the following server side changes necessary.
#### Server
We register routes in multiple places. Right now `knownRoutes` is
populated from the router created in
`cmd/frontend/internal/app/ui/router.go`, but this does not include
`/-/sign-out`. This route (and others) are defined in
`cmd/frontend/internal/app/router/router.go` (I don't know what the
difference is). I extended the sveltekit route registration code so
that's possible to register routes from multiple routers.
I couldn't test it yet however because I currently can't get Sourcegraph
to run locally (Camden tested it; it works).
### Development mode changes
After the above changes, navigating to a React only page in development,
e.g. `/insights` would show a 'repo not found error' because
`window.context.svelteKit.knownRoutes` was empty in development. So
every non-existing page would be interpreted as missing repository.
Hardcoding a list of known pages *again* just for development seemed to
be a step backwards. So I spent quite a bit of time to find a way to
extract the JS context object from the HTML page returned by the origin
server and inject it into the HTML page generated by SvelteKit, similar
to how we do it for the React app.
Additionally the value of `window.context.svelteKit.knownRoutes` is now
used to setup the proxy to non-supported pages from the server, so we
don't have to maintain this regex anymore either:
```ts
// Proxy requests to specific endpoints to a real Sourcegraph
// instance.
'^(/sign-(in|out)|/.assets|/-|/.api|/.auth|/search/stream|/users|/notebooks|/insights|/batch-changes|/contexts)|/-/(raw|own|code-graph|batch-changes|settings)(/|$)': { ... }
```
This means that requesting non-svelte pages will also return the
corresponding React version in development.
## Test plan
Manual testing.
Relates to #64186
With this PR we only show `83 out of 120 tasks` if the search job is
currently processing. In all other states, we don't show this stat. This
is a consequence of the janitor job I recently added, because after
aggregation, this data is not available anymore. User's can still
inspect the logs and download results to get a detailed view of which
revisions were searched.
I also remove an unnecessary dependency of the download links on the job
state.
## Test plan:
I ran a search job locally and confirmed that the progress message is
only visible while the job is processing and that logs and downloads are
always available.
## Changelog
- Show detailed progress only while job is in status "processing"
- Remove dependency of download links on job state
When I added this, for some reason I thought it was site admin only. As
it turns out, it shouldn't be gated to site admins only, and it makes it
particularly annoying on dotcom.
Reverts sourcegraph/sourcegraph#64014
We decided that including this in the August 7th release would be rushed
after diving deeper into the project. Reverting this in order to
re-write the functionality, especially the data loading components.
## Test Plan
- this is a revert PR. Everything will work as before.
There is no need to have a separate image file for dark mode. The SVG
file can handle color switching itself.
## Test plan
Switched theme in the user menu and in the browser dev tools.
Introduces basic (and incomplete) UI support for perforce, including displaying changelist ids,
listing changelists, and removing references to commits and branches.
The URL path for streaming blame is ambiguous when the file path
contains `/stream/`. The pattern looks like
`/blame/<repo_name>@<revision>/stream/file/path.txt`. However, if the
file contains `/stream/`, the revision is matched greedily up until the
last stream, so we end up with a revision that looks like
`81af3g/stream/my/path`, which is in invalid revision that results in a
404.
This makes the URL pattern unambiguous by adding a `/-/` element after
the revision, which is not allowed in a revision name and acts as a path
separator. So now, the pattern looks like
`/blame/<repo_name>@<revision>/-/stream/file/path.txt`.
Note, this is a public-facing breaking change, but I don't think it
really matters since I don't expect any customers use our streaming
blame API
With SRCH-802 we saw error messages when batch changes may still retry
and resolve the problem. To give a better distinction between resolvable
and non-resolvable errors, I'm changing the colour variation from error
to warning if the changeset has not been marked as `FAILED` yet.
Before:
<img width="913" alt="Screenshot 2024-08-02 at 12 44 27"
src="https://github.com/user-attachments/assets/b192c5e9-d23b-460c-82a7-a039edbca3f5">
After:
<img width="1355" alt="Screenshot 2024-08-02 at 12 36 23"
src="https://github.com/user-attachments/assets/02e231a7-168a-4fe9-bd3b-014d810fd236">
## Test plan
Manual testing
## Changelog
- Batch changes that are still retrying now show a warning instead of an
error.
Closes
https://linear.app/sourcegraph/issue/SRCH-561/add-support-for-file-ranges-in-cody-web
## Test plan
- Check that you can mention files with ranges
- Check that as you open Cody chat on the blob UI page and you have
selected lines in blob UI then chat should have an initial context
mention with line range
- Check that as you change line selection it updates mention file chip
range (only if you don't have any other text)
This PR brings the most recent version of @sourcegraph/cody-web package
- Improvements in how we fetch providers and debounce logic for their
query
- Fix with switching-chat actions and providers list
## Test plan
- Manual checks over cody web (React and Svelte version)
