When I packaged the Electron project, it didn't work

[zhushenwudi]

At present, everything is normal except the interruption problem mentioned in the last issue. We are currently working on packaging. But when I pack, the software crashes when I open it

And I use "native-ext-loader "to process webpack, it can open, but can not to convert the format.

The first question is whether formal packaging can rely on flac-bindings under the same node_modules as DEV. Or do you need to rely directly on node files. The second question is, how can my Webpack be configured to run properly if it is referenced directly under node_module? How can I modify my configuration to make it work if It is referenced through a Node file.

There is no detailed description of this aspect in readme. Maybe this is the first case of electron packing, so I may trouble you

[zhushenwudi]

[zhushenwudi]

I used node file with Node-loader to open the program, but the conversion will give an error

[melchor629]

Hi again!

Well the native code is just a wrapper from C code to node. The FileDecoder and StreamDecoder implementations are in .js files inside lib folder. Never worked with webpack and native modules so I will try to help as much as I can.

The thing is, you should load the library using the usual import ... from 'flac-bindings';, internally uses bindings to load the native code. For what I imagine, the idea is to keep the file inside one of the folders the mentioned library looks for. If you left with the usual import, the bindings should fail with a list of paths that tried to read from. In general, the native code is placed in build/Release/flac-bindings.node (the relative path is usually where flac-bindings is inside a node_modules folder).

In your case, because you are bundling the code with webpack, I'm not sure where the .node file should be placed. In the bindings code, when using webpack, uses the real require from nodejs, so maybe the file should be placed in build/Release/flac-bindings.node relative to where the electron app runs. But not sure.

Now, looking at your first screenshot, the getFileName function looks like it is from here. It seems that this function fails for some reason on your side. So looking at the bindings code, there is a way to avoid calling this function (I think).

With all this quick investigation, first I will update my native load code so it does not call to that getFileName function and then I will release the new version. I will come back to the issue when the release is ready, with some ideas I will come up to investigate this.

Thanks for raising the issue and your work on this lately :)

[zhushenwudi]

Yes, I refer to many mature third-party libraries, which seem to be loaded in the production environment "/resources" directory (win) or "/Resource" directory (MAC, Linux)

{
    test: /\.node$/,
    loader: "native-ext-loader",
    options: {
        rewritePath: targetPlatform == 'win32' ? './resources' : './Resources'
    }
}

And copy the node file to the packaging directory in the following way

"win": {
      "target": [
          "nsis"
      ],
      "extraFiles": [
          {
              "from": "node_modules/flac-bindings/build/Release/flac-bindings.node",
              "to": "./resources"
          }
      ]
  },

I have referred to this part of the code and added it to the project, but now I may be worried that your library should specify to run the files under a certain directory. I guess it should be like this. Of course, I don't know much about it here, but just speak freely

[melchor629]

Well that may work, that's a new area for me as well :/

When possible, try using the new version in which I changed a bit how the native code is loaded, and see if it loads or fails (and what is the error now).

[zhushenwudi]

OK, I'll be looking forward to it

[zhushenwudi]

That is great! The new version can be packaged and work properly. Thank you for your timely reply and code correction. Thank you very much!

[melchor629]

Glad to hear it can be packed in Electron, and works fine now! Thanks to you for rising the issue and help me improve the library :)