Bundled output references absolute path of developer's machine

[andrew0]

If I use this plugin with the esbuild bundle option set to true, the pino dependency uses the absolute path of the output directory:

    function pinoBundlerAbsolutePath(p) {
      try {
        return require("path").join("/path/to/project/on/my/machine/dist", p);
      } catch (e) {
        const f = new Function("p", "return new URL(p, import.meta.url).pathname");
        return f(p);
      }
    }

This makes it so the bundle doesn't work anywhere except the machine it was built on. I'm trying to bundle a project using pino for use in an AWS Lambda function, so the original process.cwd() path from build time won't exist at runtime.

[wd-David]

I did notice this when I was troubleshotting my docker image (multi-stage).

I need to copy exactly the same folder path like ./app/build from build stage to the final stage.
But it might not be viable for serverless function.

What do you think if the bundled code would look like this:

function pinoBundlerAbsolutePath(p) {
  try {
    return require("path").join(`${process.cwd()}/dist`, p);
  } catch (e) {
    const f = new Function("p", "return new URL(p, import.meta.url).pathname");
    return f(p);
  }
}

So it can get the runtime path with the same outdir.

[andrew0]

At least for my purposes (bundling for a lambda function), that would work fine. But I don't know if it's safe to assume that the current working directory will be next to the bundled code in all cases. For example if someone bundled code in a library, you would want pinoBundlerAbsolutePath to resolve to the bundled library in your node_modules.

Was there a problem using __dirname? It looks like that's what the pino webpack plugin is using for this function.

[wd-David]

Was there a problem using __dirname? It looks like that's what the pino webpack plugin is using for this function.

It'll break if entryPoints is set like this:

...
entryPoints: {
  first: './first.js',
  'abc/cde/second': './second.js'
},
outdir: 'dist',
...

The second.js cannot find pino files since __dirname would return /project/dist/abc/cde but pino files were generated under /project/dist.

[wd-David]

@andrew0
v1.2.1 is released and should work for you.
For bundling code in a library, I think it should work as well.

[webartoli]

A build time directory prefix still exists

Starting from this repo: https://github.com/davipon/fastify-esbuild

This works

$ node build

But more common dockerized scenarios are not because "build" prefix is defined at compile time.

$ mv build my-app
$ node my-app

$ cd build
$ node .

Please consider to refers file on the same directory removing any relative path.