* stub method to avoid unhandled exception in test from pretendRemote
* less flaky ActionItem test that checks condition before snapshotting
* rename *.{spec => test}.ts
This simplifies the test filename pattern.
* rename top-level tsconfig.all.json to tsconfig.json
* upgrade to pnpm 8.9.2
* avoid usage of jsdom.reconfigure
* more robust linkClickHandler.test.tsx
* make getBundleSizeStats.test.ts not need to use mocks
* extract createBarrier() to @sourcegraph/testing
* more robust fromObservableQuery.test.ts
* avoid jsdom.reconfigure
* do not attempt to request assets from assets.gitlab-static.net
fastmod -F assets.gitlab-static.net example.com client/browser/src/
* avoid "incorrect casing" for mocked React components
* use createBarrier
* fix SurveyToast mock GraphQL query
* fix classNames typo
* Use TypeScript project references
* Use JS for config files
* Lint only ts to work around crash on JS files
* Fix codeowners
* Tune VS Code config
* skipDefaultLibCheck
* Add Buildkite grouping to foreach-ts-project.sh
* Add better logs for pre-build.sh
* Export interface to fix private name error
This helps with #2067 and clarifies the relationship between site config and external service config.
Test plan:
- Verify that equivalent Go `./schema` code is codegenned (vs. before this PR, by looking at the diff).
- For the web app, ensure that in the site admin external service Monaco editors for each kind of service, you get hovers and validation as before.
- For the backend, ensure that server-side validation occurs when you try to save external service JSON in site admin. (This is covered by Go unit tests.)
Goal: help people write reliable UI code by making it easier to write and run tests.
Using Facebook's [jest](https://jestjs.io) for tests helps us achieve this goal because:
- jest has great first-class support for testing React components (see https://jestjs.io/docs/en/tutorial-react) and is by far the most popular way that people test React components, so the bugs are ironed out and the tooling is good
- jest can run all of our tests (`shared/`, `web/`, and `client/browser/` -- and unit tests **AND** e2e tests) from the same runner (`yarn test` in the root dir)
- jest has a great `--watch` UI and a good [vscode-jest extension](https://github.com/jest-community/vscode-jest)
- debugging tests in VS Code works with no additional effort
- jest requires a lot less configuration and code to set up testing and coverage than Mocha (no `--require ts-node --require source-map-support mocha.opts --require long-stack-traces --require esm ...`, no test-time bundling required using `unit-test-utils.ts`, etc.)
**Note:** Most of the diff is from https://github.com/skovhus/jest-codemods, which automatically updates our test code to use jest style (`describe`, `test`, `expect`, etc., not `it` and `assert`).
jest appears to be the most popular tool for solving the problem that we have (testing a large web/multi-platform application), and it was surprisingly painless to set up and a joy to use.
TODOs:
- [x] Make it pass on Buildkite
- [x] Ensure e2e, screenshots-after-failures, and coverage still work on Buildkite
- [x] Test on macOS
- [x] Add docs to repo
---
Usage:
> This is also documented in `doc/dev/testing.md` and `doc/dev/web_app.md`.
- To run all unit tests, run `yarn test` from the root directory.
- To run unit tests in development (only running the tests related to uncommitted code), run `yarn test --watch`.
- And/or use [vscode-jest](https://github.com/jest-community/vscode-jest) with `jest.autoEnable: true` (and, if you want, `jest.showCoverageOnLoad: true`)
- To debug tests in VS Code, use [vscode-jest](https://github.com/jest-community/vscode-jest) and click the **Debug** code lens next to any `test('name ...', ...)` definition in your test file (be sure to set a breakpoint or break on uncaught exceptions by clicking in the left gutter).
- e2e tests:
- To run e2e tests for the browser extension: `cd client/browser && yarn test-e2e`
- To run e2e tests for the browser extension: `cd web && yarn test-e2e`
- You can also run `yarn test` from any of the individual project dirs (`shared/`, `web/`, `client/browser/`).
Usually while developing you will either have `yarn test --watch` running in a terminal or you will use vscode-jest.
---
Notes:
- There are no regressions. The following are all preserved as before: Puppeteer screenshots after test failures, jsdom tests, e2e tests, Codecov and lcov coverage, VS Code integration, etc.
- You will need to write tests using [jest matchers](https://jestjs.io/docs/en/using-matchers) (or [jest async matchers](https://jestjs.io/docs/en/asynchronous) for async code), not `assert`. They are very similar.
- You need to use `test()` instead of `it()` for defining test cases.
* remove enterprise workspace (build together with webapp)
* remove sourcegraph-extension-api workspace
* directly import graphqlschema instead of symlinking
* remove unneeded symlink (file now lives in this package)
* noEmit on extensions-client-common & refer to graphql schema in webapp only
* update paths @sourcegraph/extensions-client-common/{lib => src}
* remove unneeded workspace for and deps from extensions-client-common
* extensions-client-common compiles
* update paths in browser-extensions
* webapp compiles with ecc node_modules deleted
* compiling after adding back ecc node_modules
* root gulpfile working
* mv packages/webapp -> web
* replace "packages/webapp" with "web"
* mv packages/browser-extensions client/browser
* remove broken phabricator dev script
see https://github.com/sourcegraph/sourcegraph/issues/938
* replace "packages/browser-extensions" with "client/browser"
* mv packages/extensions-client-common shared
* update paths
* yarn.lock for browser ext
* update paths to graphqlschema
* tslint paths
* LinkOrSpan
* update gql
* client/browser typechecks
* client/browser tslint
* tsconfig.json combining
* rearrange gulpfiles
* clean up schema gulp tasks
* before linking a lot of deps
* webpack build working
* more consolidation
* add more common deps
* almost done w browser ext
* WIP just tried adding base.config.ts symlinks true
to try to fix the issues where multiple highlight.js caused hovers to fail due to no highlighting, and multiple rxjs type errors (codeintellify and sourcegraph/sourcegraph) showing up only in webpack. hypothesis is that this is due to webpack not resolving symlinks and so "seeing" multiple pkgs.
* hovers working, fixed resolve issue, just needed to add rxjs to root package.json
* regenerate lockfiles
* add browser ext to procfile
* add back builds
* manually sync contribution.schema.json
* import schema json files directly, no copying
* update import paths
* wip typescript build doc
* move enterprise/src/ into src/ for ease of typescript build
* wip build doc
* wip
* use a single root package.json
* update yarn.lock
* prettier
* set up .bin symlinks
* prettier
* all:typecheck
* fix
* fix all:typecheck
* fix schema output path
* add back .bin links
* fix link
* fix gulpfiles
* only include gulpfile in root tsconfig
* clean up gulpfiles
* generate
* fix node_modules paths in webpack
* sort
* simplify tsconfig
* ignore generated files
* fix bundlesize paths
* fix enterprise build
* fix tsconfigs
* fix back tsconfigs
* fix
* TMP
* fix path
* TIP
* WIP
* transpileonly in tests because we have already typechecked it
* fix browser ext test
* remove browser ext from procfile for now
* fix enterprise paths
Previously, there were 2 Webpack and TypeScript builds: in `.` and `./enterprise`. This was because these used to live in separate repositories. Now that they are in the same repository, we can combine them. The benefit of combining them is reduced complexity and duplication.
The work to combine the builds consisted of:
- Removing all Webpack/TypeScript build config files from `enterprise/`, such as `tsconfig.json`, `webpack.config.ts`, `package.json`, etc.
- Rewriting import paths in `enterprise/**/*.ts?(x)` to use relative file paths instead of importing from `@sourcegraph/webapp`.
- Removing all `dist`-related tasks from the root build config. (These were only used to export a package that `enterprise/` could use in its separate build.)
In combining the builds, some additional changes were required:
- Upgraded Webpack and various Webpack-related packages.
- Switched back to the now-recommended (no longer deprecated) webpack-dev-server from webpack-serve.
- Removed the node-sass-import-once helper because (1) it did not appear to be effective and (2) it resulted in a ModuleNotFoundError when importing a `.css` file in a dependency that itself imported a `.css` file with a relative path. (The usual solution for this is to use resolve-url-loader, but that is incompatible with node-sass-import-once. The reason this problem started occurring now is likely due to upgrading sass-loader or related packages, and that was necessitated by other errors that are not worth describing here.)
- Remove thread-loader. It did not actually speed up Webpack build times.
