mirror of
https://github.com/sourcegraph/sourcegraph.git
synced 2026-02-06 15:12:02 +00:00
cff1669bc1
## UI Updates for Perforce Depots and Git Repos Fixes SRCH-530 **NOTE: This PR is a refactor of an earlier [PR](https://github.com/sourcegraph/sourcegraph/pull/64014) that was reverted. For that reason, the PR description is largely the same.** This PR introduces changes to the UI to differentiate between Perforce Depots and Git repositories. Below are the key changes included in this commit: ### 1. Dynamic Top-Level Navigation **For Perforce Depots:**  **For Git Repos:**  ### 2. Tabs on Revision Picker **For Perforce Depots:** Since we only need one tab for changelists, no tabs are shown.  **For Git Repos:** We have tabs for Branches, Tags, and Commits.  ### 3. Commits/Changelists Page **For Git Repos:** The page displays Git commits.  **For Perforce Depots:** The page displays Perforce changelists.  ### 4. Vocabulary Adjustments - We display either Git commit SHAs or Changelist IDs based on the project type. - For authorship, we use "submitted by" for Perforce and "committed by" for Git. - We refer to "Commits" for Git projects and "Changelists" for Perforce projects. **Examples:** - **For Git Commits:**  - **For Perforce Changelists:**  ### 5. URL Mapping URLs are now structured differently based on the project type: - **Commits Page:** - Git: `/[repo-name]/-/commits` - Perforce: `/[repo-name]/-/changelists` - **Individual Item Page:** - Git: `/[repo-name]/-/commit/[commit-hash]` - Perforce: `/[depot-name]/-/changelist/[changelist-ID]` When viewing a specific commit or changelist: - **Git:** `/[repo-name]@[git-commit-hash]` - **Perforce:** `/[repo-name]@changelist/[changelist-id]` _NOTE: The value displayed in the search field will also change accordingly._ ### What is left to be done? **On repo search results, when searching a revision, we still show the git commit SHA instead of the changelist ID for perforce depots:**  I plan to make a follow-up issue for this and begin work on it immediately. It's a little trickier than the other changes because in the RepositoryMatch type, there is no value that can help us determine whether a project is a depot or a repo. We need to find another way to fetch that data. ### Request for reviewers: 1. Please try to break these new features and tell me what you find. I stumbled on a number of little gotchas while working on this, and I'm sure I've missed some. ## Test plan <!-- REQUIRED; info at https://docs-legacy.sourcegraph.com/dev/background-information/testing_principles --> - Manual/Visual testing - Adjust e2e and integration tests to obtain a passing CI - Test directly visiting a URL versus getting there via click - Add unit tests for new/updated helper functions --------- Co-authored-by: Camden Cheek <camden@ccheek.com> |
||
|---|---|---|
| .. | ||
| branded | ||
| browser | ||
| build-config | ||
| client-api | ||
| codeintellify | ||
| cody-context-filters-test-dataset | ||
| cody-shared | ||
| cody-ui | ||
| common | ||
| eslint-plugin-wildcard | ||
| extension-api | ||
| extension-api-types | ||
| http-client | ||
| jetbrains | ||
| observability-client | ||
| observability-server | ||
| shared | ||
| storybook | ||
| template-parser | ||
| testing | ||
| vscode | ||
| web | ||
| web-sveltekit | ||
| wildcard | ||
| BUILD.bazel | ||
| README.md | ||
Frontend packages
List
- web: The web application deployed to http://sourcegraph.com/
- browser: The Sourcegraph browser extension adds tooltips to code on different code hosts.
- vscode: The Sourcegraph VS Code extension.
- extension-api: The Sourcegraph extension API types for the Sourcegraph extensions. Published as
sourcegraph. - extension-api-types: The Sourcegraph extension API types for client applications that embed Sourcegraph extensions and need to communicate with them. Published as
@sourcegraph/extension-api-types. - sandboxes: All demos-mvp (minimum viable product) for the Sourcegraph web application.
- shared: Contains common TypeScript/React/SCSS client code shared between the browser extension and the web app. Everything in this package is code-host agnostic.
- branded: Contains React components and implements the visual design language we use across our web app and e.g. in the options menu of the browser extension. Over time, components from
sharedandbrandedpackages should be moved into thewildcardpackage. - wildcard: Package that encapsulates storybook configuration and contains our Wildcard design system components. If we're using a component in two or more different areas (e.g.
web-appandbrowser-extension) then it should live in thewildcardpackage. Otherwise the components should be better colocated with the code where they're actually used. - search: Search-related code that may be shared between all clients, both branded (e.g. web, VS Code extension) and unbranded (e.g. browser extension)
- storybook: Storybook configuration.
Further migration plan
-
Fix circular dependency in TS project-references graph wildcard package should not rely on web and probably shared, branded too. Ideally it should be an independent self-contained package.
-
Decide on package naming and update existing package names. Especially it should be done for a shared package because we have multiple
sharedfolders inside of other packages. It's hard to understand from where dependency is coming from and it's not possible to refactor import paths using find-and-replace. -
Investigate if we can painlessly switch to
npmworkspaces. -
Content of packages shared and branded should be moved to wildcard and refactored using the latest FE rules and conventions. Having different packages clearly communicates the migration plan. Developers first should look for components in the wildcard package and then fall-back to legacy packages if wildcard doesn't have the solution to their problem yet.
-
shared contains utility functions, types, polyfills, etc which is not a part of the Wildcard component library. These modules should be moved into utils package and other new packages: e.g. api for GraphQL client and type generators, etc.
-
Packages should use package name (e.g.
@sourcegraph/wildcard) for imports instead of the relative paths (e.g.../../../../wildcard/src/components/Markdown) to avoid long relative-paths and make dependency graph between packages clear. (Typescript will warn if packages have circular dependencies). It's easy to refactor such isolated packages, extract functionality into new ones, or even into new repositories.