chore: 🤖 hoist esbuild to consolidate ember-source dependencies

[hashicc]

Description

This PR is to address an Embroider + Vite build error. The tooling reports the following issue of finding two different ember-source resolutions:

Some V1 ember addons are resolving as incorrect peer dependencies. This makes it impossible for us to safely convert them to v2 format.

  👇 👇 👇
👉 See https://github.com/embroider-build/embroider/blob/main/docs/peer-dependency-resolution-issues.md for an explanation of the problem and suggestions for fixing it.
  👆 👆 👆

[email protected] (dev)-> [email protected] -> [email protected]
    sees peerDep [email protected]
      at boundary-ui/node_modules/.pnpm/[email protected]_@[email protected]_@[email protected][email protected][email protected][email protected]_/node_modules/ember-source
    but [email protected] is using [email protected]
      at boundary-ui/node_modules/.pnpm/[email protected]_@[email protected]_@[email protected][email protected][email protected]/node_modules/ember-source

pnpm installs dependencies in its store at node_modules/.pnpm.

Currently, looking in the node_modules/.pnpm on main after a fresh pnpm install results in this set up ember-source with 2 "installations":

boundary-ui/node_modules/.pnpm/[email protected]_@[email protected]_@[email protected][email protected][email protected]
boundary-ui/node_modules/.pnpm/[email protected]_@[email protected]_@[email protected][email protected][email protected][email protected]

The only difference between these two ember-source installation sources is esbuild being included. pnpm should try to dedupe them by default. The example in the documentation is specifically around this scenario: webpack + esbuild. All the versions in the key for ember-source, @glimmer/component, @glint/template, rsvp, webpack are the same so I believe this should be deduped. The documentation mentions only version mismatches should prevent this dedupe.

This webpack + esbuild scenario arrises from the api addon package which has both webpack + esbuild:

• webpack has a dependency on terser-webpack-plugin which has an optional peer dependency on esbuild
• And ember-source depends on ember-auto-import which depends on babel-loader which depends on webpack

If you remove the esbuild from api addon, remove node_modules and run pnpm install, you'll see just one ember-source entry (the end goal):

boundary-ui/node_modules/.pnpm/[email protected]_@[email protected]_@[email protected][email protected][email protected]

While this fixes the issue of just one ember-source installation it means that esbuild isn't available for the api dependency which is needed for our worker builds. Another solution to consolidate the ember-source installation is to include esbuild anywhere we have webpack. This can be done by going to every package and including it explicitly or by hoisting it to the workspace root and then it's available to every workspace implicitly. This results in a single ember-source entry:

boundary-ui/node_modules/.pnpm/[email protected]_@[email protected]_@[email protected][email protected][email protected][email protected]

As to why the dedupe isn't working, there may be a bug? Based on that issue, the workaround is what I've done in this PR:

This is not high priority right now. You can install @nestjs/microservices and @nestjs/platform-express in the root of the workspace and you'll get a single version of @nestjs/core.

This PR installs esbuild at the root of the workspace and we get a single version of ember-source. If this bug gets fixed we can rely on deduping and remove the workspace-level installation of esbuild.

How to Test

One ember-source installation

1. Current state: two ember-source entries
   From boundary-ui root

git checkout main
git pull
rm -rf node_modules
pnpm install
ll node_modules/.pnpm | grep ember-source

See that there are two entries starting with ember-source, one with esbuild and one without

2. This branch: one ember-source entry
   From boundary-ui root

git fetch
git checkout hoist-esbuild
git pull
rm -rf node_modules
pnpm install
ll node_modules/.pnpm | grep ember-source

See that there is one entry starting with ember-source, it includes esbuild

esbuild is still working

The builds should work, and this includes the workers. This should be covered by CI and the vercel builds

Checklist

- [ ] I have added before and after screenshots for UI changes
- [ ] I have added JSON response output for API changes

• I have added steps to reproduce and test for bug fixes in the description
  - [ ] I have commented on my code, particularly in hard-to-understand areas
• My changes generate no new warnings
  - [ ] I have added tests that prove my fix is effective or that my feature works
  - [ ] I have added a11y-tests label to run a11y audit tests if needed

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.
• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.
• If applicable, I've documented the impact of any changes to security controls.
  Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
boundary-ui	Ready	Preview	Comment	Nov 6, 2025 4:55pm
boundary-ui-desktop	Ready	Preview	Comment	Nov 6, 2025 4:55pm

[hashicc]

This is another way of seeing how the installation key in node_modules/.pnpm is affected with esbuild now being included universally where ember-source is used