look for .node files in sibling directory.

[nicksrandall]

I use Lightningcss with esbuild and the "approved" way to import .node files with esbuild is to use the "copy" loader, which copies the .node file into the destination folder. Now the script that requires the .node file is a sibling of the .node file instead of a child.

[devongovett]

What is the reason for this?

[nicksrandall]

@nicksrandall added info into the description.

[devongovett]

So you are bundling lightningcss itself with esbuild? That's an interesting use case... When you install it from npm, there will be a platform-specific package installed as well, e.g. lightningcss-linux-x64-gnu. So the relative paths here should only really be used for local development of lightningcss itself. When bundling with esbuild, wouldn't the .node file actually be coming from the platform-specific package, and not the main lightningcss package?

[nicksrandall]

Yeah, I have an HTTP service (specifically an AWS lamba fn) that generates css files and we use Lightningcss to post-process the files before we deliver.

To work around this, I could also include my "node-modules" folder with the deployed service which would allow the first condition here to work.

However, I was hoping to avoid having to ship my node_modules folder (which is heavy) or coming up with logic to conditionally include certain folders (which is a challenge when tracking nested dependencies). Allowing esbuild to just do its thing and only having to copy over my built files has made our deployment process very easy/simple.

[nicksrandall]

So yes, the node file that is actually copied does come from the platform specific package. This fallback logic allows the service to find the copied node file when shipped as a single bundle without node-modules folder. Does that make sense?