[Feature Request] Skip resolving dependencies that are required inside a try/catch if the resolver throws a MODULE_NOT_FOUND error

[paul-soporan]

When a require call is inside a try/catch (e.g.

try {
  require(`dep`);
} catch {
}

), ESBuild's default resolver treats it as external and doesn't try to resolve it. This changes when I add a plugin that registers onResolve, as ESBuild will forward the require call to the resolver. The problem is that the resolver loses the context of the require call and always tries to resolve it (throwing a MODULE_NOT_FOUND error if it can't be resolved), even if the require call is inside a try/catch.

My suggestion would be to check if the error thrown has error.code === 'MODULE_NOT_FOUND' and skip it if the require call is inside a try/catch.

An alternative would be to add a new args.optional property on the resolve args so that resolver plugins can manually skip the dependency if the resolution fails.

Use case: I want to make @yarnpkg/esbuild-plugin-pnp not throw when optional peer dependencies that are required inside a try/catch are not provided by the parent (https://github.com/yarnpkg/berry/pull/2717/checks?check_run_id=2292511030#step:4:177).

[evanw]

I'm closing this issue because this is about the @yarnpkg/esbuild-plugin-pnp plugin, but that plugin is no longer relevant as esbuild now implements Yarn PnP natively. Also esbuild already ignores resolution errors for require inside try/catch, so I believe (but haven't double-checked) that if a plugin wants to do this it can just not resolve the path (i.e. return undefined) instead of throwing a specific magic error code and this will already work.

[arcanis]

@evanw This isn't a PnP issue - any custom resolver may hit the same issue. Since Esbuild doesn't report whether the resolution is within a try block, plugins can't know whether they need to return undefined or an actual error message.