Support tsconfigRaw in build

[hardfist]

since esbuild only follows a subset of typescript config, it may help to list the supported typescript compiler options like what @babel/plugin-transform-typescript does, https://babeljs.io/docs/en/babel-plugin-transform-typescript#typescript-compiler-options,
and it seems that tsconfigRaw only supports in transform, why not supports it in build ?

[evanw]

I think this is a duplicate of #923. I'm keeping that issue open until I document the supported tsconfig.json options.

[hardfist]

will you support rawtsconfig in build？

[hardfist]

@evanw we want to fully control what user set in tsconfig.json(like what babel does when babelrc set to false https://babeljs.io/docs/en/options#babelrc), are you going to support this feature?

[evanw]

Ah set of supported tsconfig.json features has been documented for a while now: https://esbuild.github.io/content-types/#tsconfig-json. Sorry I didn’t update this issue.

For the build API, you can use the tsconfig option instead of tsconfigRaw option and write the content to a file.

[hardfist]

Why not build also supports tsconfigRaw, pass an file path to build may be a problem for browser environment which lacks fs support

[djgrant]

@hardfist I would also like this feature but resolving baseUrl/paths needs a filesystem. During the resolution stage, esbuild is interacting with the filesystem to determine how import paths should be resolved.

For example, given a path mapping paths: { "~/*": ["src/*", "src/generated/*"] }, there is no way to determine whether to use the first path or the fallback path to construct the resolved path without inspecting the file system.

@evanw Looking through the issues there seems to be interest for resolving virtual modules by people using the WASM version of esbuild. It's fairly painful re-implementing and maintaining tsconfig baseUrl/path resolution and ESM/CJS module resolution from scratch within plugins. Is there any possibility of piggy-backing on esbuild's built-in resolution mechanics?

I suspect the answer is no, but, for example, could some callbacks be provided to proxy interactions with the filesystem? Eg:

{
  fileExists(lookupPath: string): boolean | Promise<boolean>
  getFile(resolvedPath: string): string | Promise<string>
}