Loading tooling configs via Plugin API

[swandir]

ESBuild offers onResolve and onLoad plugin hooks, which enable working without FS access, but not fully. ESBuild still tries to read some special files that affect resolution/transformation/bundling, e.g. tsconfig.json or package.json.

While some of cases are covered by onResolve by re-implementing full resolution algorithm in the plugin, others are not possible.

For example, when you use extends from a package in Yarn PnP environment, you get this warning:

▲ [WARNING] Cannot find base config file "@tsconfig/vite-react"

    tsconfig.json:2:13:
      2 │   "extends": "@tsconfig/vite-react"
        ╵              ~~~~~~~~~~~~~~~~~~~~~~

And it actually does break the build, because tsconfig affects code transformation.

This specific case can (and maybe should) probably be fixed by utilizing onResolve/onLoad for loading base tsconfigs, but there's also package.json and potentially other special files.

It could be worked around by using ESBuild only as a transformer rather than a full bundler and taking care of all the configs in onResolve (that's what Vite currently does, for example). But at the expense of having re-implement bundling outside of ESBuild.

I'm not familiar with ESBuild internals, but seems like a config loading hook in the Plugin API would enable utilizing ESBuild bundling in environments where ESBuild can't read from the file system.

[hyrious]

I'm wondering how other bundlers (e.g. rollup/webpack) deal with tsconfig hiding in yarn@berry storages. For example, will they bring up resolveId/load hooks on tsconfig.json and package.json, or they just do some extra work to support yarn?

[swandir]

I'm wondering how other bundlers (e.g. rollup/webpack) deal with tsconfig hiding in yarn@berry storages. For example, will they bring up resolveId/load hooks on tsconfig.json and package.json, or they just do some extra work to support yarn?

It'd work as long as they resolve paths through require.resolve (or similar) and access the file-system via node's fs module (Yarn patches both for PnP support). Then it'd be the same as loading from node_modules.

Tsconfig's "extends" follows the node-style module resolution — not sure if it goes through onResolve in ESBuild though. At least I have the same warning even if I extend a tsconfig from a Yarn workspace, which is in a real directory next to the current one. Reading it directly would seem to work given that the path is properly resolved. But since the file can be in the cache, loading it through a plugin would be necessary in the general case anyway.

[evanw]

I'm going to close this because esbuild has since implemented native support for Yarn PnP (see #2451), which should fix this class of issues. I recognize that this fix isn't exactly what you're proposing since you're thinking about the general case while esbuild only fixed this for Yarn PnP, but I think the remaining use cases could be covered by something like #690.