Outputfile path varies based on dynamic imports

[japettyjohn]

I have some TS files which I'm bundling and when I add dynamic imports which are outside of the folder of the entry point, then the file for the entry point is output in a subfolder.

Example:

ts/app.ts

import 'lazysizes'

console.log('Hello, world!');

Then running:

esbuild ./ts/app.js --bundle --format=esm --splitting --minify --sourcemap --public-path=/js/module/ --outdir=public/js/module

Results in:

public
public/js
public/js/module
public/js/module/app.js.map
public/js/module/app.js

But with dynamic imports it is different.

ts/app.js

import('lazysizes');

console.log('Hello, world!');

package.json

{
  "dependencies": {
    "lazysizes": "^5.3.0"
  },
  "name": "testing"
}

Then running the same command as above results in:

public
public/js
public/js/module
public/js/module/node_modules
public/js/module/node_modules/lazysizes
public/js/module/node_modules/lazysizes/lazysizes.js.map
public/js/module/node_modules/lazysizes/lazysizes.js
public/js/module/ts
public/js/module/ts/app.js.map
public/js/module/ts/app.js

I am getting this from the CLI and from the Go API as well.

The path to app.js should be consistent, or short of that, expose it in the BuildResult.

[evanw]

This is because dynamic imports are entry points too, and the directory structure that esbuild generates inside the output directory is by default relative to the lowest common ancestor directory of all entry points. If the default isn't suitable for you, you can specify it explicitly with the outbase setting: https://esbuild.github.io/api/#outbase.

[japettyjohn]

Thanks, using the outbase is a workable solution for my purposes.

I'm not sure the benefits of the doing the lowest common ancestor, but in order to use that in a more automated workflow, I would need a way to resolve where the entry point landed to reference it dynamically. Use case for this would be a site builder, e.g. Hugo, would do something like this:

<script src="{{EntryPoint("./ts/app.ts")}}">

That would correlate to what the entrypoint setting was in the config and resolve to the final output file based on what you described.

[evanw]

Thanks, using the outbase is a workable solution for my purposes.

Ok, good to hear. Sounds like this issue is resolved for you then, so I'll close this issue.

I'm not sure the benefits of the doing the lowest common ancestor

It's just to have the default behavior do something reasonable. People naturally expect a single build to output a single file instead of a deep hierarchy, but at the same time don't want collisions between multiple entry points that have the same name in different subdirectories. The LCA approach naturally solves for both desires. AFAIK Rollup does this too.

I would need a way to resolve where the entry point landed to reference it dynamically

Using outbase is the simplest way of doing this at the moment. The eventual solution I have in mind is to use the metafile JSON metadata file to list out where each entry point ends up. Then you would just look up the entry point in that file. This is going to be required once entry point file names end up having hashes in them (see #518).