Release 0.4.1

[FlorianRappl]

We did not have a full release for a while - I think the 0.4.1 (which is more like a 0.5.0; open to change the version here) is ready.

Let's move forward?

[github-actions]

pr-comment: Run #47

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Pending ⏳	Other ❓	Flaky 🍂	Duration ⏱️
1400	1238	0	0	0	162	0	4m 8s

🎉 All tests passed!

Github Test Reporter by CTRF 💚

[softworkz]

Wait a moment - my publish builds are suddenly failing.

This could have a thousand reason - but: When I'm building the same commit on AzDo which was building successfully two weeks ago, it's failing now.

I suspect some npm dependency. The error is basically that the app code doesn't get copied into resources/bin anymore.

Just reproduced with Electron.NET (linux-x64) as well (you don't see an error here - just the files don't get copied anymore)

[softworkz]

This is something that completely breaks Electron.NET as it seems!

When you try to reproduce, can you backup any pre-existing package-lock.json files that you might still have?

Like [project]\bin\Release\net10.0\win-x64\.electron\package-lock.json

[softworkz]

This is so sick....

While investigating further with the Electron.NET solution and after I have successfully reproduced the issue with both, Linux and Windows publishing. using ElectronNET.WebApp.

Later I tried with the console app and unexpectedly it was working there. It was very confusing, because that's the model which my own (also failing) app is using as well. After many theories and more testing, I tried with ElectronNET.WebApp again - and damn: it can't be true - it was working as well....

We all know these kinds of situation and when somebody tells a story like above, it's a clear case: User Error!

And I would have been inclined to assume that I must have done something stupid accidentally - but there's one little caveat: The DevOps build.

Two weeks ago, it ran successfully
Today - a few hours ago - it failed (3 of 3 attempts) - and now it's working again.

I have no explanation for this...

_{of course: always the same commit on AzDo and the pipeline definition wasn't touched)}

[softworkz]

It was caused by multiple updates to the minimatch library:

https://www.npmjs.com/package/minimatch?activeTab=versions

(there's a "dependabot" PR for this, but already outdated)

[FlorianRappl]

Ok so do we need to do something (pin minimatch resolution to a certain version?) or is this already contained / fixed with their latest release?

[softworkz]

Yea, that's a good question - surely worth to stop thinking about how to catch up the lost time - for a moment.

I'm not deeply familiar with npm, so I don't have an immediate answer to this, but let's look at the facts first:

• I assume that minimatch is a transitive electron-builder dependency which resolves the -exrtraresources bin/**/.* cli parameter of e-b - haven't followed the dependency-path yet
• We cannot have use package-lock.json file where we could pin to specific versions, because it depends on dynamic factors
  • The selected electron-builder version (and its dependencies)
  • Maybe also the electron version selection and the dependencies of that selected version
  • Custom user-defined dependencies (if using ElectronHostHook
• The package.json and package-lock.json files are merely some kind of intermediate files for building and disposable at any time, so trying to get into that mechanism and attempting to persist the lock file somehow, would likely do more harm than any good

Now, what I'm wondering about is this:

minimatch has been updated 3 times in the past 24h. How does it even happen that npm installs the newest version each time? I mean, nuget doesn't do that. It chooses the highest required min version for each library, but it never uses a newer version when there's no forcing requirement.
I wonder whether npm can be configured in a way that it behaves more like nuget in this regard?

[FlorianRappl]

minimatch has been updated 3 times in the past 24h. How does it even happen that npm installs the newest version each time? I mean, nuget doesn't do that. It chooses the highest required min version for each library, but it never uses a newer version when there's no forcing requirement.

It only installs the most recent matching version. The matching part is governed by semver ranges, which are specified in the dependencies field of the package.json. This, of course, applies for deps of deps, too. As an example, electron-builder itself has no dependency on minimatch. We - as an example - also don't have a direct dependency.

The semver ranges are always respected - unless you specify overrides (other package managers such as Yarn call them resolutions). This way, you can even control the versions for deps of deps.

Some package managers such as pnpm introduced rules to avoid most recent releases (e.g., by setting a minimum time - this way circumventing potential issues with freshly published packages).

[softworkz]

Hmm - sounds like there's not much we can do then..?

[FlorianRappl]

I'd say so.

[softworkz]

Then we're good to go. 🚀