Failure to resolve yarn-linked packages when bundling

[midsbie]

Attempting to produce a bundle results in a fatal failure to resolve packages correctly when esbuild sees an import chain consisting of dependencies that have been symlinked via yarn link.

This happens when an import dependency is linked (via yarn link) and it, in turn, imports a dependency that is also linked via the same mechanism. When faced with this particular type of import chain, esbuild fails to resolve the second dependency.

No failure occurs when the packages aren't linked. Webpack handles linked dependencies correctly.

Reproduction case

Unpack the attachment, then follow the steps below.

1. Install dependencies in monorepo

$ cd monorepo-source
monorepo-source$ yarn install
yarn install v1.22.10
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 0.90s.

2. Link packages

monorepo-source$ yarn workspaces run yarn link
yarn workspaces v1.22.10
                                                                                                       
> @monorepo-source/a
yarn run v1.22.10
warning package.json: No license field
$ /monorepo-source/node_modules/.bin/yarn link
warning package.json: No license field
warning package.json: No license field
warning There's already a package called "@monorepo-source/a" registered. This command has had no effect. If this command was run in another folder with the same name, the other folder is still linked. Please run yarn unlink in the other folder if you want to register this folder.
Done in 0.19s.
                                                                                                       
> @monorepo-source/b
yarn run v1.22.10
warning package.json: No license field
$ /monorepo-source/node_modules/.bin/yarn link
warning package.json: No license field
warning package.json: No license field
warning There's already a package called "@monorepo-source/b" registered. This command has had no effect. If this command was run in another folder with the same name, the other folder is still linked. Please run yarn unlink in the other folder if you want to register this folder.
Done in 0.23s.
Done in 0.84s.

3. Install dependencies in implementation repo

monorepo-source$ cd ../impl
impl$ yarn install
yarn install v1.22.10
info No lockfile found.

[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
                                                                                                       
success Saved lockfile.
Done in 1.42s.

4. Link local monorepo-source package

monorepo-source$ yarn link @monorepo-source/b

5. Attempt to build

impl$ npx esbuild --bundle index.ts
 > ../../../.config/yarn/link/@monorepo-source/b/src/index.ts: error: Could not resolve "@monorepo-source/a" (mark it as external to exclude it from the bundle)
    1 │ import { foo } from '@monorepo-source/a';
      ╵                     ~~~~~~~~~~~~~~~~~~~~

1 error

Yarn-linked directory structure

$ ls -Gg ~/.config/yarn/link/@monorepo-source/
total 0
lrwxrwxrwx 1 53 Feb 7 12:11 a -> ../../../../monorepo-source/packages/a
lrwxrwxrwx 1 53 Feb 7 12:11 b -> ../../../../monorepo-source/packages/b

A personal note of gratitude

Can't miss the opportunity to express my deep appreciation for this wonderful tool that you've created and keep refining over time and at such an exhilarating pace too. Thank you for making web development less insane!

reproduction-case.zip

[evanw]

Thanks for the reproduction case and very detailed instructions! This made it easy for me to figure out what was wrong. Turns out the reason is just that symlinks pointing to symlinks was not implemented yet:

esbuild/internal/fs/fs_real.go

Lines 328 to 330 in a2a221e

	if (mode & os.ModeSymlink) != 0 {
	return // Symlink chains are not supported
	}

I didn't want to implement that without an actual real-world test case to demonstrate that it works correctly, so I left it unimplemented. Now that I have your test case it was easy to get working. The fix for this issue will be in the next release.