* move test_helpers to the core
* create base tsconfig
* all tsconfigs use the base one
* use test_helpers exposed from the src/core
* move getFieldFormatsRegistry to data plugin
* add test_utils project
* compile types after checkout
* add a stub for platform tsconfig.json
* fix broken import
* fix broken path to the base config
* set tsBuildInfoFile for project without outDir
* do not commit tsbuildinfo file
* do not check output d.ts files
* fix type error
* use separate config to build types
* rollback changes to include paths
* mute import zone error
* rename files to avoid references to tsd
* do not use tsd for type tests
* include all ts files in project
* run buildRefs before type check to ensure the latest version
* store tsbuildinfo locally
* update paths to base config
* comment out core/tsconfig.json
* remove ui path
* fix wrong tsbuildinfo path
* [typescript] continue to use the default config in development
In #21865 we tried to make a separate config file that would be used for
browser TS files by excluding them from the default config file and
adding a second that included them. This works fine in the build, but
IDE integrations rely on being able to automatically discover a
`tsconfig.json` file in a parent directory of the file being edited,
which doesn't work when the tsconfig.json file is found, but excludes
the file being edited. In this situation IDE integrations silently
fallback to the default TSConfig settings, which don't show the types of
compiler errors that will become issues in CI, like implicit any
warnings.
This implements the original strategy we tried in #21865 of mutating the
tsconfig.json file before we run the tsc in the build so that the config
files select the right files at build time.
* [tslint] remove browser config from default projects list since it is empty
* [build/ts] fix typo
Right now the build process is running TypeScript code through a single transpilation process which produces the JS code that ships with the distributable. This process causes problems because when running the optimizer from source we use a slightly different config 33c6ade756/src/optimize/base_optimizer.js (L312-L313), which instructs typescript to build modules using ESM, which webpack understands, but in the build we transpile this TypeScript to commonjs, which does not support features that are important to the strategy we are using to maintain BWC with the legacy platform as we migrate to the new platform.
This implements a `tsconfig.browser.json` file at the root of the repository that extends the default `tsconfig.json` file and includes a `src/**/public/**/*` code, which the root `tsconfig.json` file now excludes. This new config file is added to the list of projects that we lint, is shared with webpack, and is built along with the default project in the build process to create JS code that uses esm for webpack to consume.
