[v2] nsis: add files

[pronebird]

This PR adds support for files for NSIS installer, similar setting can be found under macOS configuration. The rationale for adding this is the following:

• Other platforms already support bundling additional platform-dependent files.
• Using files section makes it possible to bundle external binaries and their resources under individual folders. External binaries setting does not provide such flexibility.

Further thoughts

Making custom installer.nsi is difficult. It would be better to provide a way to have a pre and post install hooks. Maybe we could include custom .nsh files that would augment the behavior of templates/installer.nsi.

This is still work in progress and I am not able to test it. Somehow I keep stumbling upon the following error which is a dead end given that it does mention the source of this error:

Error [tauri_cli] failed to bundle project: The system cannot find the file specified. (os error 2)

Closes #9652

[FabianLars]

Using files section makes it possible to bundle external binaries and their resources under individual folders. External binaries setting does not provide such flexibility.

The resources feature does though (the docs still weren't updated but it accepts objects to configure source and target paths). Doesn't really matter since i agree with you that it makes sense to add this for the sake of cross platform consitency, but still wanted to mention it x)

[pronebird]

Using files section makes it possible to bundle external binaries and their resources under individual folders. External binaries setting does not provide such flexibility.

The resources feature does though (the docs still weren't updated but it accepts objects to configure source and target paths). Doesn't really matter since i agree with you that it makes sense to add this for the sake of cross platform consitency, but still wanted to mention it x)

That's good to know. However resources are located at the bundle level. Given that I use one tauri.conf.json for all platforms, all assets specified under resources would end up in each installer that I build.

Right now I am using resources to bundle assets that are used on all platforms, macOS > files to ship third-party binaries and their assets for macOS. That trick didn't work on windows.

Even if windows > nsis > files were allowed, I'd still need a way to run custom pre-install and post-install scripts which in my case set-up windows service on Windows, or launch daemon on macOS. So for the time being, I had to resort to to the custom installer.nsi. The tauri installer.nsi template is 800 LOC long and if I could only tap into some parts of it without copying the whole thing, that would make it so much easier to build the installer.

[FabianLars]

That's good to know. However resources are located at the bundle level. Given that I use one tauri.conf.json for all platforms, all assets specified under resources would end up in each installer that I build.

Right now I am using resources to bundle assets that are used on all platforms, macOS > files to ship third-party binaries and their assets for macOS. That trick didn't work on windows.

You can have OS specific configs (that overwrite the main config) -> https://tauri.app/v1/api/config#platform-specific-configuration

Even if windows > nsis > files were allowed, I'd still need a way to run custom pre-install and post-install scripts which in my case set-up windows service on Windows, or launch daemon on macOS. So for the time being, I had to resort to to the custom installer.nsi. The tauri installer.nsi template is 800 LOC long and if I could only tap into some parts of it without copying the whole thing, that would make it so much easier to build the installer.

I did not disagree with the "Further thoughs" section of your PR description, i just think it's off-topic with this PR and should have its own issue/PR :)

[pronebird]

That's good to know. However resources are located at the bundle level. Given that I use one tauri.conf.json for all platforms, all assets specified under resources would end up in each installer that I build.

Right now I am using resources to bundle assets that are used on all platforms, macOS > files to ship third-party binaries and their assets for macOS. That trick didn't work on windows.

You can have OS specific configs (that overwrite the main config) -> https://tauri.app/v1/api/config#platform-specific-configuration

Even if windows > nsis > files were allowed, I'd still need a way to run custom pre-install and post-install scripts which in my case set-up windows service on Windows, or launch daemon on macOS. So for the time being, I had to resort to to the custom installer.nsi. The tauri installer.nsi template is 800 LOC long and if I could only tap into some parts of it without copying the whole thing, that would make it so much easier to build the installer.

I did not disagree with the "Further thoughs" section of your PR description, i just think it's off-topic with this PR and should have its own issue/PR :)

Thanks again. The merged config could work in my case, at least I wouldn't have to copy files manually.

Since it's not documented how to write the resources map, could you please maybe shed some light on how does one specify the glob pattern in map, i.e should it be this:

"resources": {
  "tray-icons/": "tray-icons/*.png",
}

or that?

"resources": {
  "tray-icons/*.png": "tray-icons/*.png",
}

I'll make sure to create another issue in regards of nsis installer hooks.

Update: it seems that resource map works different from files, for example if I want to bundle a binary from target/release folder, the bundler errors, stating that the file already exists, which tells me that it must be copying files.

Maybe that's because when building a universal mac binary, my workspace binaries aren't compiled into universal-apple-darwin folder and so the copying mechanism works fine, but on Windows everything falls into target/release.

If I got it right, the syntax is inverted here, i.e key is path to file, value is where to put it in installer. Keys and values are flipped in that sense in macos > files

"resources": {
  "../../target/release/my-other-bin.exe": "my-other-bin.exe"
}

I'll create an issue for that too 😓

[amrbashir]

I see no reason to include this option, as your use-case is already covered by resources map and the other files option (.deb for example) is to copy files into subdirectories within the .deb file not the final install location. It also doesn't have any APIs to resolve access to them.