Fix the workers path calculations

[segevfiner]

1. Remove pinoBundlerRan check in case there are multiple pino.js modules around, might fix some cases of the __bundlerPathsOverrides being missing leading to it looking for lib/worker.js and failing
2. Use a simple __dirname based strategy for pinoBundlerAbsolutePath, more complex outputs layout might require some more thought on how to figure out the relative path from the current file to the workers if they are not together - fixes Using process.cwd is problematic #159
3. Move pinoBundlerAbsolutePath into a virtual module so it can safely use import.meta.url or __dirname depending on the format. This makes it work in ESM mode, minus the "Dynamic require is not supported" issue of esbuild, which needs a workaround in your esbuild config - How to fix "Dynamic require of "os" is not supported" evanw/esbuild#1921

[wd-David]

Thank you for the PR.
I have limited time to investigate the solution, so it would be great if you could update the test files according to the change.

[segevfiner]

more complex outputs layout might require some more thought on how to figure out the relative path from the current file to the workers if they are not together - fixes #159

They are failing due to having a test that checks such a scenario as I wrote in the PR description, and I can't figure out a way to handle it.

Essentially we are pushing our patch into the pino.js module which gets loaded just once even for multiple entry points, __dirname resolves at runtime to the directory containing this entry point, and we have no obvious way to know where the rest of the entry points are, that is, the additional worker entry points we added. esbuild doesn't seem to handle require.resolve and similar to entry points ATM. I'm not really sure if esbuild has any mechanism to get the correct path to another entry point ATM when they are spread out like this.

The problem is that using process.cwd or absolute paths, as currently used is not helpful, as it makes the bundle either not relocatable, or dependent on the working directory, which is not a reliable way to load your files as that can be anything for a program a user is going to launch via CLI for example. So this just kinda punts the problem into the user invoking to set the working directory to where those worker files are...

I guess one workaround is to make pinoBundlerAbsolutePath be a find-up like search... Though we will need to depend on that module or implement our own version of it.

Unless esbuild has some way to correctly inject the relative path to another entry point @evanw?

[segevfiner]

Offf is there really no way to require.resolve or something similar the id of an entrypoint or an alias to it and have esbuild correct the path to it so the require.resolve works at runtime... @evanw

Why oh why is everything so goddamn difficult in JS...

[OoDeLally]

Hi, any news from this fix ? Currently this problem makes the whole package unusable, as bundles contain absolute path from my dev machine... 🤷

[segevfiner]

Unfortunately no. I haven't figured out a way to get the relative path to an entry point bundle from esbuild...