Describe the user story
As a maintainer of a Yarn-based runtime, I want @yarnpkg/builder build bundle to support an executable ESM bundle mode and an explicit list of external modules, so runtimes that are ESM-only can use the official builder without patching the published @yarnpkg/builder package.
Today build bundle hardcodes an IIFE output format and a Node-engine-derived target. It also doesn't expose an external option for dependencies that must remain runtime-resolved. Projects that need an ESM-only runtime bundle currently have to patch the builder package globally, which is brittle and hard to share upstream.
Describe the solution you'd like
Add first-class opt-in options to builder build bundle, for example:
--format esm|iife, defaulting to the current IIFE behavior;--target <value>, defaulting to the current Node target;- repeatable
--external <specifier> entries passed to esbuild for bundle-time externals.
For --format esm, the emitted bundle should remain directly executable by Node and include the small Node compatibility setup needed by existing bundle code paths such as require, __filename, and __dirname.
Describe the drawbacks of your solution
This would add a small builder CLI surface area and expose a few esbuild-shaped concepts through Yarn's builder. The default behavior should stay unchanged, and the new options would need tests proving that existing IIFE bundles are unaffected.
The ESM executable mode also needs a narrow definition for the compatibility setup, so it doesn't become a generic hook for arbitrary bundle banners.
Describe alternatives you've considered
A contrib plugin isn't enough because the requested behavior belongs to builder build bundle, which is the tool producing the runtime bundle.
Patching @yarnpkg/builder works as a local workaround, but it makes downstream projects depend on a global monkey patch of the published builder package.
Running esbuild directly would avoid the patch, but then downstream projects lose the Yarn-specific builder behavior and have to maintain a parallel bundling route.
I found related issues such as #6211 and #1678, but they don't seem to cover ESM output and explicit externals for builder build bundle.
Describe the user story
As a maintainer of a Yarn-based runtime, I want
@yarnpkg/builder build bundleto support an executable ESM bundle mode and an explicit list of external modules, so runtimes that are ESM-only can use the official builder without patching the published@yarnpkg/builderpackage.Today
build bundlehardcodes an IIFE output format and a Node-engine-derived target. It also doesn't expose anexternaloption for dependencies that must remain runtime-resolved. Projects that need an ESM-only runtime bundle currently have to patch the builder package globally, which is brittle and hard to share upstream.Describe the solution you'd like
Add first-class opt-in options to
builder build bundle, for example:--format esm|iife, defaulting to the current IIFE behavior;--target <value>, defaulting to the current Node target;--external <specifier>entries passed to esbuild for bundle-time externals.For
--format esm, the emitted bundle should remain directly executable by Node and include the small Node compatibility setup needed by existing bundle code paths such asrequire,__filename, and__dirname.Describe the drawbacks of your solution
This would add a small builder CLI surface area and expose a few esbuild-shaped concepts through Yarn's builder. The default behavior should stay unchanged, and the new options would need tests proving that existing IIFE bundles are unaffected.
The ESM executable mode also needs a narrow definition for the compatibility setup, so it doesn't become a generic hook for arbitrary bundle banners.
Describe alternatives you've considered
A contrib plugin isn't enough because the requested behavior belongs to
builder build bundle, which is the tool producing the runtime bundle.Patching
@yarnpkg/builderworks as a local workaround, but it makes downstream projects depend on a global monkey patch of the published builder package.Running esbuild directly would avoid the patch, but then downstream projects lose the Yarn-specific builder behavior and have to maintain a parallel bundling route.
I found related issues such as #6211 and #1678, but they don't seem to cover ESM output and explicit externals for
builder build bundle.