8296e9804f
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. |
||
|---|---|---|
| .. | ||
| 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.