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. |
||
|---|---|---|
| .. | ||
| __mocks__ | ||
| bookmarklet | ||
| dev | ||
| dist | ||
| src | ||
| tests-examples | ||
| .bazelignore | ||
| .eslintignore | ||
| .stylelintrc.json | ||
| BUILD.bazel | ||
| bundlesize.config.js | ||
| package.json | ||
| README.md | ||
| statoscope | ||
| tsconfig.json | ||
| vitest.config.ts | ||
Web Application
Local development
Use sg CLI tool to configure and start local development server. For more information check out the sg documentation.
Our local development server runs by starting both a Caddy HTTPS server and a Node HTTP server. We then can reverse proxy requests to the Node server to serve client assets under HTTPS.
Configuration
Environment variables important for the web server:
WEB_BUILDER_SERVE_INDEXshould be set totrueto enable serving of an index page.SOURCEGRAPH_API_URLis used as a proxied API url. By default it points to the https://k8s.sgdev.org.
It's possible to overwrite these variables by creating sg.config.overwrite.yaml in the root folder and adjusting the env section of the relevant command.
Development server
sg start web-standalone
Public API
To use a public API that doesn't require authentication for most of the functionality:
SOURCEGRAPH_API_URL=https://sourcegraph.com sg start web-standalone
Production server
sg start web-standalone-prod
Web app should be available at https://${SOURCEGRAPH_HTTPS_DOMAIN}:${SOURCEGRAPH_HTTPS_PORT}. Build artifacts will be served from <rootRepoPath>/client/web/dist.
Note: If you are unable to use the above commands (e.g. you can't install Caddy), you can use sg run web-standalone-http instead. This will start a development server using only Node, and will be available at http://localhost:${SOURCEGRAPH_HTTP_PORT}.
API proxy
In both environments, server proxies API requests to SOURCEGRAPH_API_URL provided as the .env variable.