Will there be any issues during user upgrades or overlay installations? Since the paths change each time, will uninstalling previous versions fail due to missing paths?

I suggest using fixed paths, such as including the type (nsis/squirrel) in the path, rather than generating random paths. Some uninstallation processes require these fixed paths for proper removal.

It used to be this develar@8738e18

    const uninstallerPath = path.join(this.outDir, `.__uninstaller-${this.name}-${process.pid.toString(16)}-${Date.now().toString(16)}.exe`)

I can't seem to track down the commit/PR that changed it to its current form.

The prefix __uninstaller doesn't exist anywhere else in the codebase either https://github.com/search?q=repo%3Aelectron-userland%2Felectron-builder%20__uninstaller&type=code

The uninstallerPath is passed to install.nsi through UNINSTALLER_OUT_FILE.

Apps registered through registry or in Settings/Apps/Uninstall Apps may have issues, we need to test and verify.

  WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APP_NAME}" "UninstallString" '"${UNINSTALLER_OUT_FILE}"'

If we use a fixed path, then we completely cannot have parallel builds of nsis target.
We could theoretically switch it back to a tmp-dir with a fixed name, but then that goes explicitly against the comment above it: // it is more safe and reliable to write uninstaller to our out dir

The problem is that I can't identify the why based off the issue linked in the comment.

@beyondkmp @xyloflake what if we just had a unique directory name within the out directory? Then we keep the uninstaller name as a constant? That way we still respect the comment of "reliability outputting to out dir" while maintaining the static name.

Previous implementations were these, so I think we'd still be satisfying the original intent while not introducing regressions:

packager.getTempFile("uninstaller.exe") // completely temp dir/file elsewhere on the filesystem
```
```
path.join(this.outDir, `.__uninstaller-${this.name}-${process.pid.toString(16)}-${Date.now().toString(16)}.exe`) // within outDir but non-static file name
```

@beyondkmp @xyloflake what if we just had a unique directory name within the out directory? Then we keep the uninstaller name as a constant? That way we still respect the comment of "reliability outputting to out dir" while maintaining the static name.

Previous implementations were these, so I think we'd still be satisfying the original intent while not introducing regressions:

packager.getTempFile("uninstaller.exe") // completely temp dir/file elsewhere on the filesystem

path.join(this.outDir, `.__uninstaller-${this.name}-${process.pid.toString(16)}-${Date.now().toString(16)}.exe`) // within outDir but non-static file name

I personally think that is a GREAT idea. I think it should be something like: if concurrency is enabled, then it should use the unique directory in the out folder and if it doesn't have concurrency enabled then it should fallback to this old method. But I think even if there is no fallback, this is a great idea and I think it's pretty necessary for parallelization!

@beyondkmp, thinking on this further, I think we can just use the installerPath since it should always be unique to each installer being built, regardless of archs since that's calculated previously into the artifact name (installer path)

const uninstallerPath = path.join(this.outDir, `${path.basename(installerPath, "exe")}__uninstaller.exe`)

Can delete else

Wait, why?

Wait, why?

Same question, I believe that is a necessary conditional

Apologized for the misunderstanding.
I mean

 if (poolCount < 1) {
        log.warn({ concurrency: poolCount }, "concurrency is invalid, overriding with job count: 1")
        poolCount = 1
  } 
 if (poolCount > MAX_FILE_REQUESTS) {}

However, this is just a coding convention, it's optional to change it.