ESM rewritten relative paths are wrong

[aubergene]

Given a structure like this

├── package.json
├── server.ts
└── src
    ├── index.ts
    ├── sub1
    │   └── index.ts
    └── sub2
        └── index.js

when I run the following

npx esbuild server.ts src/**/index.{ts,js} --format=esm --bundle --external:'./node_modules/*' --platform=node --target=node16.13 --outdir=dist --outbase=.

then the import paths are all rewritten to be relative as ../node_modules which is correct for the top level but it wrong for all levels below. I've tried reading the docs carefully and various incantations of outbase etc but haven't been able to get it to work. I'm also somewhat unclear as to why it's rewriting them at all, as presumably leaving external imports untouched would work?

In the dist dir I see the following

✅ correct

// server.ts
import { range } from "../node_modules/d3-array/src/index.js";
console.log(range(13));

🚫 broken

// src/index.ts
import { range } from "../node_modules/d3-array/src/index.js";
console.log(range(131));

🚫 broken

// src/sub1/index.ts
import { range } from "../node_modules/d3-array/src/index.js";
console.log(range(13));

[susiwen8]

I think this is correct behaviour, cause esbuild will bundle all file into single file, the structure looks like

-dist
  -test.js
-node_modules
-src
 -test.ts
 -a
  -a.ts
 -b
  -b.ts

However I found potential bug for outbase, I have set outbase: '.', the output file located in dist/src/test.js , which is incorrect for node_modules path.

here is my build script

build({
    entryPoints: ['./src/test.ts'], 
    format: 'esm',
    external: ['./node_modules/*'],
    platform: "node",
    target: "node16.13",
    outdir: 'dist',
    outbase: '.',
    bundle: true
})

[aubergene]

Thanks, yes, it feels like the expected behaviour should be the import path is relative to outbase for each file

[susiwen8]

it feels like the expected behaviour should be the import path is relative to outbase for each file

I second that

[evanw]

This general type of issue has been reported before: #1958 and #2164. I tried to support the "mark all packages as external" use case by reusing an existing mechanism (--external) but it didn't quite work, for various reasons. I'm planning to fix this by changing --external to just pass the paths through without any modification instead of turning them into relative paths at all. I haven't done that yet because it's a breaking change, but I still plan to do it. Can you confirm that this would work for your use case?

[aubergene]

Yes thank you that would fix it! Also big thank you for all your time making esbuild!

[wonskarol]

I'm planning to fix this by changing --external to just pass the paths through without any modification instead of turning them into relative paths at all. I haven't done that yet because it's a breaking change, but I still plan to do it.

Do you know when you will release this version? I ask out of curiosity as we are considering using esbuild and it is currently blocking us.

[gmanninglive]

I'm planning to fix this by changing --external to just pass the paths through without any modification instead of turning them into relative paths at all. I haven't done that yet because it's a breaking change, but I still plan to do it.

Do you know when you will release this version? I ask out of curiosity as we are considering using esbuild and it is currently blocking us.

You've probably got something sorted now, but if not this plugin @evanw wrote fixes this for me.

Any imports that don't start with "/" or "./" or "../" are left alone

[malthe]

@evanw not sure about that plugin, but it would be great if this just worked out of the box.