zbar.wasm
zbar.wasm copied to clipboard
building fails with esbuild
Since the last update, I'm not able to build with esbuild
I get something like this (using 2.1.1, it was working before)
esbuild --bundle --minify --loader:.bin=file --loader:.wasm=binary --sourcemap src/index.js --outfile=public/main.js
node_modules/zbar.wasm/dist/zbar.js:9:1075: error: Could not resolve "path" (use "--platform=node" when building for node) 9 │ ..."+toLog)}var nodeFS;var nodePath;if(ENVIRONMENT_IS_NODE){if(ENVIRONMENT_IS_WORKER){scriptDirectory=require("path").dirname(scriptDirectory)+"/"}else{scriptDirectory=_dirname+"/"}read=function shell_read(filename,binary... ╵ ~~~~~~
node_modules/zbar.wasm/dist/zbar.js:9:1216: error: Could not resolve "fs" (use "--platform=node" when building for node) 9 │ ..."/"}else{scriptDirectory=_dirname+"/"}read=function shell_read(filename,binary){if(!nodeFS)nodeFS=require("fs");if(!nodePath)nodePath=require("path");filename=nodePath"normalize";return nodeFS["readFileSync... ╵ ~~~~
If I had --platform=node, it works but then it doesn't seem to build properly the wasm file
Uncaught (in promise) RuntimeError: Aborted(both async and sync fetching of the wasm failed). Build with -s ASSERTIONS=1 for more info.
Before it was creating a bin file in my public folder
I guess that is why I had decided not to use the bundle js. This issue happend in the old webpack but now webpack seems to work fine.
Anyway, seems like your are trying to build a frontend bundle. Can you check if esbuild is using the load-browser.ts
instead of load.ts
?
And we could have a different build for load-browser.ts
to avoild the node dependencies to make the bundler happy.
yes, it's using load-browser (i've tried with import { scanImageData } from "../zbar.wasm/dist/load-browser.js";)
i think it's due to this line const zbar_1 = __importDefault(require("./zbar")); that has some node dependencies
@samsam2310 this seems to work, i had to set path and fs as external. still i guess that's adding unnecessary code for the browser?
esbuild --bundle --minify --external:path --external:fs --loader:.bin=file --loader:.wasm=binary --sourcemap src/index.js --outfile=public/main.js
As a side note, Webpack 4 + file-loader 6.2.0 handle zbar.wasm
as they should now, so maybe the zbar.wasm.bin
workaround is no longer necessary.
This would also remove the necessity for configuring the server to serve *.wasm.bin
as application/wasm
which is non-standard.
That is great.
So we could:
- Remove the wasm.bin workaround.
- Build a different zbar.js for browser. (Pass arguments to emcc to build only for Web / Worker env)
@samsam2310 Please take a look at the zbar.js
generated by emcc (needs to be de-minified first). It can load zbar.wasm
properly in browsers (XMLHttpRequest
), in Node (using fs
and path
) and as Web worker in both browsers and Node, depending on the runtime environment.
I am using this successfully for minified builds of a ZBar ES module, a CommonJS module and a browser script in this branch of my fork of your repo. Polyfilling fs
and path
for browsers currently adds a few KByte, but this could be avoided by polyfilling with stubs.
I know what the bundle is. If you see the readme in v1.0.0, you can find the document about polyfilling fs
and path
.
But removing them is not that hard and can make our life easier.
@samsam2310 I couldn't find any notion of polyfilling fs
and path
in the Readme in v1.0.0. Could you throw a link at me, please? ;)
https://github.com/samsam2310/zbar.wasm/tree/4cc3408006636041e72ec1764866067090a45f3f#how-to-include