"!node_modules/?angular${/*}" in files doesn't exclude node_modules/@angular folder

[tim-wilkins]

25.0.5

• Electron-Builder Version:

v20.12.0

• Node Version:

32.0.2

• Electron Version:
• Electron Type (current, beta, nightly):

n/a Windows, msi

• Target:

This worked with 24.13.3 and electron 32.0.1, but I noticed that the asar file had grown a lot and extracting it find the angular folder with contents. All versions are updated using "ng update electron" etc. when "npm outdated" shows an outdated version. I do also have electron-reload@1.5.0 (not updated since only alpha).

[mmaietta]

The only change I was able to find in the diff that might be related is an upgrade from "minimatch": "^5.1.1", to "^10.0.0"

Can you try force-resolving/overwriting the version of minimatch in your package.json to 5.1.1 and see if that resolves the issue? If so, I can open a PR asap and get it into the next release

[absidue]

@mmaietta I tried overriding the minimatch version with yarn but it complained about the versions being too far apart and ignored the override. In our case we tell electron-builder to ignore the node_modules folder entirely because we use webpack to bundle the files first. Going from 24.13.3 to 25.0.5, resulted in electron-builder pulling in packages in the node_modules folder that start with @, even things like babel which are listed in the development dependencies which electron-builder is supposed to ignore by default. For the moment we have reverted back to the previous electron-builder version that we were using.

On an unrelated note the newer version of electron-builder logs that it is adding asar integrity data, even though we don't even use that and the docs don't list any obvious way to stop electron-builder doing that unnecessary work (bit like how there doesn't seem to be a way to turn off code signing completely).

[mmaietta]

Ah, I used to have a project that took the same approach (bundle all files first).

Would you mind trying v25.1.5? It updated app-builder-bin dependency multiple times due to some bugs it had in parsing the dependency tree.

For disabling sign, I think you can set configuration property win.sign or (or the new win.signtoolOptions.sign in next version of electron-builder) to a noop function. I'm not sure what your use case is, but signing is highly recommended

[absidue]

With that version electron-builder install-app-deps takes forever. According to task manager app-builder.exe is using a bunch of CPU and has very slowly increasing RAM usage (been running for over 10 minutes and currently sitting at 230MB of RAM usage), so it is going to be a while before I can report back on whether that upgraded version fixes the original problem or not.

As for why we don't use code signing, it comes with various downsides that make it unsuitable for an open source project maintained by various unrelated individuals, such as costing lots of money (especially when you consider that creating a signing certificate for macos requires buying a mac first), requires tying your legal details to the app and requires tying it to someones personal Microsoft account and Apple ID or setting up a company to tie it to a company account.

If you know any way of signing apps that doesn't come with those downsides I would love to hear it.

[mmaietta]

Ahhh, my apologies. I mean 25.1.6, that version has the fix for the app-builder-bin bug that causes that memory loop.

[absidue]

A lot faster with that version but unfortunately the @ package problem still exists:

This is what we pass to the files option in the electron-builder config object:

[
  '_icons/iconColor.*',
  'icon.svg',
  './dist/**/*',
  '!dist/web/*',
  '!node_modules/**/*',
]

[mmaietta]

Could you share a minimum repro repo/gist/zip that I could test locally with?