WebUI Error: File not found (./webui-2-x64.dyn)
justinmchase opened this issue · 7 comments
deno run --allow-read main.ts
WebUI Error: File not found (./webui-2-x64.dyn) or (/x/webui@2.3.0/src/webui-2-x64.dyn)
Where are these published and what is the recommended way to package and deliver these binaries?
The pre-built binaries are in the main library repo here:
https://github.com/webui-dev/webui/releases
Usually, import { webui } from "https://deno.land/x/webui@2.3.0/mod.ts"; should download those pre-built binaries.
I don't see anywhere in the code where it would download the binary...
A couple of points of review also.
-
Pin your imports to a specific version instead of using the versionless "latest" module, especially for deprecated API's those will just be removed one day and this entire module will stop working for everyone when it does.
https://github.com/webui-dev/deno-webui/blob/main/src/webui.ts#LL13C62 -
Don't use sync fs apis, put the logic to download the libs and load the window in an async function and only use async / await and async apis.
https://github.com/webui-dev/deno-webui/blob/main/src/webui.ts#L72 -
In javascript/typescript function names should be camelCased instead of snake_cased.
-
It looks like there is a line to actually download the file missing from right here:
https://github.com/webui-dev/deno-webui/blob/main/src/webui.ts#L107-L108 -
Generally speaking, I would not store state in a module but export a class which when instantiated will create the state, or a function which when called will return the state.
https://github.com/webui-dev/deno-webui/blob/main/src/webui.ts#L19-L20
I don't see anywhere in the code where it would download the binary
Sorry, I'm not the original creator of Deno-WebUI, but I guess the binaries are already embedded in the Deno Module. Please correct me if I'm wrong.
Pin your imports to a specific version instead of using the versionless "latest"
I Agree 👍
Don't use sync fs apis
Yes, You are right. That's why the comment says "Todo". We should implement it as soon as possible.
It looks like there is a line to actually download the file
Good point. We should add code there to download the binaries if somehow they are missed.
In javascript/typescript function names should be camelCased instead of snake_cased
I would not store state in a module but export a class
Probably those two implementations should have a different PR, so we discuss it because this is going to change the public APIs, but it's a good idea, and yes, I agree with you we should do this.
They are downloadable through the module import urls but nothing seems to be actually importing them. Deno won't automatically import things, its not quite like nodejs where they all get downloaded at the same time, it will only download what you import and you can only import js/ts files. So for other files such as json or dyn or even text files you have to actually use the fetch api to download the files explicitly or you have to have some other packaging mechanism, such as if you were to first install it onto your machine globally and have these modules know where to find the files via environment variable or something.
Based on what I can tell people are just downloading the files out of band and putting them onto their local file systems at the right local path.
Here is a library some use for this purpose:
https://deno.land/x/plug@1.0.2
I got it, so Deno won't automatically download the complete package like Nodejs. Okay, I will try to implement all your suggestion (without using the plug module) when I have free time. Or, somebody will do it.
PR 1
- Pin your imports to a specific version instead of using the versionless "latest"
- Don't use sync fs apis
- It looks like there is a line to actually download the file
PR 2
- In javascript/typescript function names should be camelCased instead of snake_cased
- I would not store state in a module but export a class
Many Thanks to @JOTSR. He impliment everything 👍