mirror of
https://github.com/sourcegraph/sourcegraph.git
synced 2026-02-06 16:51:55 +00:00
de613e92b6
Use [esbuild](https://esbuild.github.io/) instead of Webpack for builds of `client/web`, for faster builds (dev and prod) and greater dev-prod parity. This PR completely removes all use of Webpack in this repository. `client/web` is the last build target that still uses Webpack; all others have been recently migrated to esbuild. Most devs here have been using esbuild for local dev of `client/web` for the last 6-12 months anyway. The change here is that now our production builds will be built by esbuild. All sg commands, integration/e2e tests, etc., continue to work as-is. The bundlesize report will take a while to stabilize because the new build products use different filenames. ## Benchmarks Running `pnpm run generate && time pnpm -C client/web run task:gulp webBuild` and taking the `time` output from the last command: - Webpack: 62.5s - esbuild: 6.7s Note: This understates esbuild's victory for 2 reasons: (1) because esbuild is building both the main and embed entrypoints, whereas Webpack only builds the main entrypoint in this benchmark) and (2) because a lot of it is in the fixed startup time of `gulp`; esbuild incremental rebuilds during local dev only take ~1s. ## Notes We no longer use Babel to produce web builds (we use esbuild), so we don't need any Babel plugins that optimize the output or improve browser compatibility. Right now, Babel is only used by Jest (for tests) and by Bazel as an intermediate step.
30 lines
3.3 KiB
Markdown
30 lines
3.3 KiB
Markdown
# 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](https://marketplace.visualstudio.com/items?itemName=sourcegraph.sourcegraph).
|
|
- **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 `shared` and `branded` packages should be moved into the `wildcard` package.
|
|
- **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-app` and `browser-extension`) then it should live in the `wildcard` package. 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
|
|
|
|
1. 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.
|
|
|
|
2. Decide on package naming and update existing package names. Especially it should be done for a **shared** package because we have multiple `shared` folders 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.
|
|
|
|
3. Investigate if we can painlessly switch to `npm` workspaces.
|
|
|
|
4. 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.
|
|
|
|
5. **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.
|
|
|
|
6. 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.
|