mirror of
https://github.com/sourcegraph/sourcegraph.git
synced 2026-02-06 19:51:50 +00:00
e014f5e257
## Bazel It took me some time to figure out how to make it work. I don't claim that this is the best setup (because I don't really have an idea what I'm doing here), I just tried to get things working. The main issues had been around loading the generate `client/*` packages and importing `*.scss` files. ### Loading `@sourcegraph/*` packages Unlike our other build tools, SvelteKit/vite load the application into Node for pre-rendering. This happens regardless whether pre-rendering/server-side-rendering is enabled or not (these settings live in the source code because they can be enabled/disabled per route). Long story short I had to configure vite to also process any `@sourcegraph/*` packages in order to make them compatible with node. You might wonder why that's not necessary when running vite directly in the repo? In the repo the `@sourcegraph/*` dependencies are all links to the corresponding `client/*` packages. Vite detects that and automatically treats them as "sources", not dependencies. ### SCSS files Somewhat related to the previous point, the built `@sourcegraph/*` packages do not contain any source SCSS files, only the generated CSS files. So importing SCSS files via `@sourcegraph/.../....scss` doesn't work. Furthermore, the generate code in the packages themselves import SCSS files, which also doesn't work. The "fix" for this is to rewrite any `*.scss` file imports to `*.css` file imports, but only inside those packages or only referencing files inside those packages. That's what we do in our `webpack.bazel.config.js` file as well. However, for global styles we need the SCSS files. I added a new target for copying those to the sandbox. --- Additionally this PR makes the following changes: - Rearrange style imports to remove unnecessary duplication and reduce the number of callsites that import from `@sourcegraph/*` packages. - Remove React integration with Notebooks and Insights. It was broken anyway at the moment and removing it reduces the number of dependencies and therefore points of failure. - Added a new target to copy the image files used by the prototype into the sandbox. - Disables gazelle for the sveltekit package for the time being. Type checking won't pass anyway because the code in the other client packages don't follow the same restrictions as `client/web-sveltekit`. - Updated the main header and dev server to proxy requests for notebooks, code insights and user settings to sourcegraph.com. ## Production build integration These changes make it possible to serve the SvelteKit version for search and repo pages when the `enable-sveltekit` feature flag is turned on. I aimed to make as few changes to the existing routing and handler code as possible to - server the SvelteKit index page for search and repo routes - make all other SvelteKit assets accessible via the `/.assets/` route In a nutshell, this is how it works now: - When building for development, the SvelteKit build process will output its files to `ui/assets/`, the same folder where webpack puts its files. To avoid conflicts with webpack generated files, all SvelteKit files are put in a subdirectory. - For production something similar happens except that bazel will copy all the files into a target directory - When accessing a search or repo route, we check, just before the response is rendered, whether to render the SvelteKit version or the React version. The challenge here was that we use the same handler for a lot of routes. `sveltekit.go` maintains a separate list of routes for which the SvelteKit version is available. This way I only had to add a check to three handler functions. And of course the feature flag must be enabled for the user/instance. - Because the SvelteKit files are stored in the same location as the webkit ones, serving those files via the `/.assets/` route "just works". Well, mostly. In order for the SvelteKit page to use the correct root-relative path I had to create a custom adapater, `sgAdapter`, which updates the URLs in the index page accordingly (I tried a lot of other approaches, some would have required changes to the assets handler... this was the more "contained" solution). Caveat: This is not ready to be officially tested: - Navigating between the React and SvelteKit versions does not always work as expected. Because of client side routing, navigating to e.g. the search page from the React app will load the React version of the site. The client side code needs to be updated to enforce a server refresh. I'll look into that in a future PR. - The SvelteKit version is relatively incomplete. Code intel, new search input, repo settings pages, etc are all missing. Most of this work is tracked in #55027. But before we spend more time getting things feature complete we want to do limited testing with the prototype in prod. - I wasn't able to get SvelteKit rebuilding to work reliably with `sg start enterprise-bazel`. For now it only builds the files once at start so that they exist. I'll look into improving the developer experience when running the full server locally in the future. For now, running `sg start web-sveltekit-standalone` is good enough. - Switching between the React and the SvelteKit version is definitely noticeable during development. I suspect to be faster in production (React is faster in production). Whether or not we go this route remains to be seen. Maybe we are embedding React pages into SvelteKit instead. At this point we just need to try how SvelteKit feels in production. - The SvelteKit `index.html` page lacks many things that the React `app.html` file has (e.g. preview links, analytics, observeability, etc). These have to be added eventually, but those are not necessary either for this initial test.
24 lines
679 B
JavaScript
24 lines
679 B
JavaScript
// @ts-check
|
|
const { spawn } = require('child_process')
|
|
|
|
/**
|
|
* buildSvelteKit is supposed to be used to build the SvelteKit
|
|
* artifacts for the enterprise development build.
|
|
*/
|
|
function buildSvelteKit() {
|
|
// We cannot progmatically start Vite because the SvelteKit plugin
|
|
// expects the current working directory to be the project root
|
|
// (client/web-sveltekit in our case). Hence we spawn a child
|
|
// process with the correct working directory.
|
|
return spawn('pnpm', ['run', 'build', '-l', 'error'], {
|
|
stdio: 'inherit',
|
|
cwd: __dirname,
|
|
shell: true,
|
|
env: { ...process.env },
|
|
})
|
|
}
|
|
|
|
module.exports = {
|
|
buildSvelteKit,
|
|
}
|