esbuild-wasm (works for esbuild) fails to resolve imports from 'nodePaths' when entrypoints are not in the toplevel dir

[KKoukiou]

commit e982017ccf013c4b196c51fe22fbf355dd14e15f (HEAD -> master)
Author: Katerina Koukiou <kkoukiou@redhat.com>
Date:   Fri Mar 17 13:59:15 2023 +0100

    Esbuild-wasm does not respect nodePaths when entrypoint is nested

diff --git build.js build.js
new file mode 100644
index 0000000..986e684
--- /dev/null
+++ build.js
@@ -0,0 +1,18 @@
+#!/usr/bin/env node
+
+import esbuild from "esbuild-wasm";
+
+const nodePaths = ['./lib'];
+
+const context = await esbuild.context({
+    bundle: true,
+    entryPoints: ["./pkg/blue/Blue.jsx"],
+    loader: {
+        ".js": "jsx",
+    },
+    nodePaths,
+    outdir: "./dist",
+});
+
+await context.rebuild();
+context.dispose();
diff --git lib/Color.jsx lib/Color.jsx
new file mode 100644
index 0000000..e21ff5d
--- /dev/null
+++ lib/Color.jsx
@@ -0,0 +1,5 @@
+import * as React from 'react';
+
+export const Color = (props) => {
+    return <div class='mycolor'>{props.children}</div>;
+};
diff --git package.json package.json
new file mode 100644
index 0000000..c695c89
--- /dev/null
+++ package.json
@@ -0,0 +1,10 @@
+{
+  "type": "module",
+  "sideEffects": false,
+  "devDependencies": {
+    "esbuild": "^0.17.10",
+    "esbuild-wasm": "^0.17.10",
+    "react": "^18.2.0",
+    "react-dom": "^18.2.0"
+  }
+}
diff --git pkg/blue/Blue.jsx pkg/blue/Blue.jsx
new file mode 100644
index 0000000..9372f4b
--- /dev/null
+++ pkg/blue/Blue.jsx
@@ -0,0 +1,6 @@
+import * as React from 'react';
+import { Color } from 'Color.jsx';
+
+export const Blue = () => {
+    return <Color>blue</Color>;
+};

Running esbuild-wasm here fails to resolve Color.jsx file from ./lib directory

[kkoukiou@sequioa test-esbuild-wasm-node-resulution]$ node build.js 
✘ [ERROR] Cannot read directory "lib/Color.jsx": Invalid argument

/home/kkoukiou/repos/test-esbuild-wasm-node-resulution/node_modules/esbuild-wasm/lib/main.js:1626
  let error = new Error(`${text}${summary}`);
              ^

Error: Build failed with 1 error:
error: Cannot read directory "lib/Color.jsx": Invalid argument
    at failureErrorWithLog (/home/kkoukiou/repos/test-esbuild-wasm-node-resulution/node_modules/esbuild-wasm/lib/main.js:1626:15)
    at /home/kkoukiou/repos/test-esbuild-wasm-node-resulution/node_modules/esbuild-wasm/lib/main.js:1038:25
    at /home/kkoukiou/repos/test-esbuild-wasm-node-resulution/node_modules/esbuild-wasm/lib/main.js:983:52
    at buildResponseToResult (/home/kkoukiou/repos/test-esbuild-wasm-node-resulution/node_modules/esbuild-wasm/lib/main.js:1036:7)
    at /home/kkoukiou/repos/test-esbuild-wasm-node-resulution/node_modules/esbuild-wasm/lib/main.js:1048:9
    at new Promise (<anonymous>)
    at requestCallbacks.on-end (/home/kkoukiou/repos/test-esbuild-wasm-node-resulution/node_modules/esbuild-wasm/lib/main.js:1047:54)
    at handleRequest (/home/kkoukiou/repos/test-esbuild-wasm-node-resulution/node_modules/esbuild-wasm/lib/main.js:713:19)
    at handleIncomingPacket (/home/kkoukiou/repos/test-esbuild-wasm-node-resulution/node_modules/esbuild-wasm/lib/main.js:735:7)
    at Socket.readFromStdout (/home/kkoukiou/repos/test-esbuild-wasm-node-resulution/node_modules/esbuild-wasm/lib/main.js:663:7) {
  errors: [
    {
      detail: undefined,
      id: '',
      location: null,
      notes: [],
      pluginName: '',
      text: 'Cannot read directory "lib/Color.jsx": Invalid argument'
    }
  ],
  warnings: []
}

When using the esbuild binary instead of the esbuild wasm, it works as expected, so this issue is only present for the esbuild-wasm.

Using full path instead of the relative path in the nodePaths, does not seem to help either.

[KKoukiou]

Workaround is to either use full paths when importing or omit the file extension.
So,

+import { Color } from '../lib/Color.jsx';

or

+import { Color } from 'Color';

[evanw]

Thanks for the report. It looks like this is because Go returns EINVAL instead of ENOTDIR with WASM, unlike Unix. I will work around this in esbuild itself.

[martinpitt]

Amazing, thanks @evanw for the super-fast fix!