AssemblyScript / assemblyscript

A TypeScript-like language for WebAssembly.
https://www.assemblyscript.org
Apache License 2.0
16.93k stars 663 forks source link

Reading from "node:fs/promises" is not handled by plugins (Unhandled scheme) #2301

Open EightR0ad opened 2 years ago

EightR0ad commented 2 years ago

getting an error when using webpack import build file(debug.js):

ERROR in node:fs/promises
Module build failed: UnhandledSchemeError: Reading from "node:fs/promises" is not handled by plugins (Unhandled scheme).
Webpack supports "data:" and "file:" URIs by default.
You may need an additional plugin to handle "node:" URIs.
    at E:\1工作\3测试\2022\assemblyscript研究\wasmWebpackTest\node_modules\webpack\lib\NormalModule.js:832:25
    at Hook.eval [as callAsync] (eval at create (E:\1工作\3测试\2022\assemblyscript研究\wasmWebpackTest\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:6:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (E:\1工作\3测试\2022\assemblyscript研究\wasmWebpackTest\node_modules\tapable\lib\Hook.js:18:14)
    at Object.processResource (E:\1工作\3测试\2022\assemblyscript研究\wasmWebpackTest\node_modules\webpack\lib\NormalModule.js:829:8)
    at processResource (E:\1工作\3测试\2022\assemblyscript研究\wasmWebpackTest\node_modules\loader-runner\lib\LoaderRunner.js:220:11)
    at iteratePitchingLoaders (E:\1工作\3测试\2022\assemblyscript研究\wasmWebpackTest\node_modules\loader-runner\lib\LoaderRunner.js:171:10)
    at runLoaders (E:\1工作\3测试\2022\assemblyscript研究\wasmWebpackTest\node_modules\loader-runner\lib\LoaderRunner.js:398:2)
    at NormalModule._doBuild (E:\1工作\3测试\2022\assemblyscript研究\wasmWebpackTest\node_modules\webpack\lib\NormalModule.js:819:3)
    at NormalModule.build (E:\1工作\3测试\2022\assemblyscript研究\wasmWebpackTest\node_modules\webpack\lib\NormalModule.js:963:15)
    at E:\1工作\3测试\2022\assemblyscript研究\wasmWebpackTest\node_modules\webpack\lib\Compilation.js:1371:12

import code:

import { multiply } from "./debug.js";
for (let i = 0; i < 10; i++) {
  const left = new Array(16);
  const right = new Array(16);
  for (let j = 0; j < 16; j++) {
    left[j] = Math.random();
    right[j] = Math.random();
  }

  const result = await multiply(left, right);
  console.debug(result);
}

next is webpack configuration:

const path = require("path");
const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = {
  context: __dirname,
  entry: {
    app: "./src/index.js",
  },
  output: {
    filename: "app.js",
    path: path.resolve(__dirname, "dist"),
    sourcePrefix: "",
  },
  amd: {
    toUrlUndefined: true,
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: "src/index.html",
    }),
  ],
  mode: "development",
  devtool: "eval",
  experiments: {
    topLevelAwait: true,
  },
};
ericblade commented 2 years ago

... how is this 'completed'? how did this get resolved? Having this issue right now.

dcodeIO commented 2 years ago

The node: scheme is a relatively recent addition. If I read correctly, it has meanwhile been backported to several earlier Node versions, but might still require updating Node.js.

ericblade commented 2 years ago

sure, using node 16, it seems to be a problem on the webpack side not on the node side.

xgqfrms commented 1 year ago

image

Projects deployed by Vercel also have this problem.

But it works fine in my local environment using Node.js 18.x.

phidvss55 commented 1 year ago

Hi @xgqfrms Have you fixed this error? I'm facing this and have no idea how to fix this.

The bug happened when I run yarn run build or deployed on Vercel

amirgamil commented 1 year ago

still facing this issue too

xgqfrms commented 1 year ago

@phidvss55 Try it out.

It's worked for me.

https://nextjs-ssr.xgqfrms.xyz/

image

image

robinmuhia commented 1 year ago

Did any of you get a viable solution?

QasimRRizvi commented 1 year ago

Any solution for this?

riccardolinares commented 1 year ago

Same error!

Ginowine commented 8 months ago

I'm still having this issue, any solution yet?

insanityfarm commented 8 months ago

I am also having this problem! Not sure why the issue is closed.

CountBleck commented 8 months ago

Can't you set the resolve.fallback["node:fs/promises"] property to be false? (see here)

dcodeIO commented 8 months ago

If this problem is so common, perhaps we should just remove the node: here?

https://github.com/AssemblyScript/assemblyscript/blob/de174c5f2863ea7947ba4496be4f9028c99d3367/src/bindings/js.ts#L980

insanityfarm commented 8 months ago

@CountBleck That doesn't work because of this webpack bug. I also tried some of the workarounds discussed in that thread, like externals['node:fs/promises'] = 'commonjs2 node:fs/promises' and some variations on that theme, with no success.

insanityfarm commented 8 months ago

@dcodeIO I tried removing node: from my generated bindings file and that resolved the issue. I'd rather not strip that out manually every time I build, so that upstream fix seems like a good solution to me. I don't know how that would impact Node use cases though.

Edit: I also had to set resolve.fallback.fs to false in my webpack config.

insanityfarm commented 8 months ago

Okay, sorry for the spam — I found a solution that works with the bindings code as-is. I was close earlier... I needed to make the following additions to my webpack config:

{
    ...
    externals: {
        'node:fs/promises': 'commonjs2 node:fs/promises',
    },
    resolve: {
        fallback: {
            fs: false
        }
    }
}

I had tried this earlier and was getting another error which I didn't realize was unrelated. (It was a runtime error caused by the browser trying to resolve that same import, which should be unreachable in that context... turns out it wasn't, because the WebAssembly.compileStreaming() call in the try block was failing, because my CSP didn't include 'unsafe-eval'.) Hope this information is helpful to others.

CountBleck commented 8 months ago

@Ginowine Does the above work for you?