Closed icheered closed 1 year ago
RReverser
commented
1 year ago Do you mean for usage from Node.js or just for frontend distribution?
It's certainly possible, you'd just need to create a package that wraps the JS+Wasm files in this project.
icheered
commented
1 year ago I mean that a user can do a yarn add web-gphoto2 and then be able to use the WASM API in any framework.
However I'm not sure what are things needed during buildtime and what things are actually needed for running the package. From quick filesystem analysis it seems that just the ui/libapi.* items are needed? (I don't have much experience with (p)react and I'm struggeling to distinguish between the framework and the newly provided web-gphoto2 functionality haha).
icheered
commented
1 year ago I'm getting a bit stuck unfortunately. I created a package and repository (both temporary, several things are not fixed like license and readme)
But currently I'm running into issues like the word __dirname being present in libapi.mjs (scriptDirectory=__dirname+"/") which gives errors when importing the package. Manually removing that word __dirname resolves these errors, but I'm not sure if I'm breaking stuff.
But the bigger issue: The libapi.mjs file uses the require keyword. When I import the package into a different project (Svelte in my case) this gives the error: "Internal server error: require is not defined". I tried changing some built parameters in the Makefile in the hopes of it outputting ES6 syntax but I haven't been succesful.
What strikes me is that your demo does not have this error even though your UI code uses ES6 syntax. How is that possible?
RReverser
commented
1 year ago Hmm those paths in libapi.mjs should not be reachable from the Web, they only trigger from Node.js code but as you noted this library was only built and used from the Web before, and successfully so. I'm not sure why Svelte complains, but also I don't have much free time to look into this deeper at the moment.
FWIW I don't think you need a separate repo, I'd prefer the end result to be a PR to package.json in this one so it all stays together and is easily discoverable.
icheered
commented
1 year ago Once I get it working I'll be sure to make a PR! For now this is just testing and trying to get it to work. I understand if you don't have time to look into it. I will try to get as far as possible by myself, if you happen to find a little time to try some stuff it would be very much appreciated!
icheered
commented
1 year ago Done! The reason the package wasn't working is because Svelte statically analyzes the files in the build toolchain so require is seen as a statement, and the build toolchain doesn't know it is inside a condition that will never be true in a browser environment (if(ENVIRONMENT_IS_NODE)). Thus, it tries to process it and fails because require doesn't exist in the target (browser) environment.
I have created a PR with everything you need to publish this project to NPM in #7 . Please let me know if you have any feedback or suggestions!
plainsquirrel
commented
1 year ago Thank you very much. I've been trying to use this repository in the Sveltekit, Electron environment for the past few weeks. However, I was unable to solve the aforementioned problem due to my low level of development skills. I'm really looking forward to it.
Thank you very much.
RReverser
commented
1 year ago Done! The reason the package wasn't working is because Svelte statically analyzes the files in the build toolchain so require is seen as a statement, and the build toolchain doesn't know it is inside a condition that will never be true in a browser environment (
if(ENVIRONMENT_IS_NODE)). Thus, it tries to process it and fails because require doesn't exist in the target (browser) environment.
Ah you might want to try adding -s ENVIRONMENT=web,worker to linking flags. That should remove all (most?) Node.js codepaths.
Maybe also upgrade Emscripten Docker version while at it just in case there were more fixes.
icheered
commented
1 year ago Maybe also upgrade Emscripten Docker version while at it just in case there were more fixes.
I have tried for a bunch of hours to try and accomplish this but I was ultimately unsuccessful. For some reason environment flags are starting to behave weird when upgrading so the EM_CACHE variable is not correctly transitioned into the build process which crashes everything. I tried to switch to 3.1.44 (latest release)
RReverser
commented
1 year ago Ok then leave the upgrade for now, just change the ENVIRONMENT. (UPD I see you did already)
RReverser
commented
1 year ago This is now published on npm: https://www.npmjs.com/package/web-gphoto2
Thanks @icheered!
sshanmu91
commented
10 months ago
First of all: Awesome project. This is exactly the type of application that I hoped would be made possible by the introduction of WASM.
Now onto the question: I read that you're no longer supporting this project but it is still quite capable in its current version. I have never done it before, but would it technically be possible to turn this into an NPM package? I have very little experience with WASM or the other tools you used to built this application, but I imagine this would be quite popular with other programming photographers.