Arch Linux User Repository

From version 3.27.0-3 and later

Instead of using the windows binary, this version will build the app from sources, targeting Electron version 13.6.y.
If you prefer the other way, then install scratch3-bin instead.

Before starting the installation, please check your disk space, the PKGBUILD won't do it for you.

Total size of the build directory on my system: 1.9 GiB (2 009 713 885)

Tested successfully under KDE/Plasma X11 arch=x86_64.

Any feedback are welcomed.

@IssacReay: I think I found a fix to circumvent the issue.
I added nodejs-lts-fermium in the makedepends to replace nodejs during build.
Scratch3 won't build with nodejs version 16 and above (2 issues at least)
so you have to accept the replacement.
After package build you can revert to nodejs if you wish.

Hello, I built your package with some error.

...
renderer: Keeping electron-webpack default rule for /\.(html)$/
10% building 1/2 modules 1 active ...loader/lib/index.js??ref--6!/home/isaac/projects/scratch3/src/scratch-desktop-3.29.1/src/main/index.jsError: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:71:19)
    at Object.createHash (node:crypto:140:10)
    at module.exports (/home/isaac/projects/scratch3/src/scratch-desktop-3.29.1/node_modules/webpack/lib/util/createHash.js:135:53)
    at NormalModule._initBuildHash (/home/isaac/projects/scratch3/src/scratch-desktop-3.29.1/node_modules/webpack/lib/NormalModule.js:417:16)
    at handleParseError (/home/isaac/projects/scratch3/src/scratch-desktop-3.29.1/node_modules/webpack/lib/NormalModule.js:471:10)
    at /home/isaac/projects/scratch3/src/scratch-desktop-3.29.1/node_modules/webpack/lib/NormalModule.js:503:5
    at /home/isaac/projects/scratch3/src/scratch-desktop-3.29.1/node_modules/webpack/lib/NormalModule.js:358:12
    at /home/isaac/projects/scratch3/src/scratch-desktop-3.29.1/node_modules/loader-runner/lib/LoaderRunner.js:373:3
    at iterateNormalLoaders (/home/isaac/projects/scratch3/src/scratch-desktop-3.29.1/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
    at iterateNormalLoaders (/home/isaac/projects/scratch3/src/scratch-desktop-3.29.1/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
    at /home/isaac/projects/scratch3/src/scratch-desktop-3.29.1/node_modules/loader-runner/lib/LoaderRunner.js:236:3
    at /home/isaac/projects/scratch3/src/scratch-desktop-3.29.1/node_modules/loader-runner/lib/LoaderRunner.js:127:6
/home/isaac/projects/scratch3/PKGBUILD: line 88: cd: /home/isaac/projects/scratch3/src/scratch-desktop-3.29.1/dist/renderer/: No such file or directory
==> ERROR: A failure occurred in build().
    Aborting...
...

Some latest openssl error with JS, i guess from my experience. However, i couldn't fix it.

Version 3.29.1

I've tested Scratch3 with all versions of Electron, from version 13 to 18.
Because of an issue in Electron affecting all version above v13,
best experience is still given by Electron13.

That's why I choose version 13 in the PKGBUILD, even if it isn't maintained
anymore (v14 and v15 either).

Anyway, If one still want to use another version, just edit lines 9 and 10 of the PKGBUILD,
and define the version number one want to use. For instance:

_electronDist=electron16
_electronVersion=16.2.5  # should be the current proposed version number

then build the package and one should be fine.

@etaboon,

Till then, I can put Eslint back if something goes wrong without it. On my system, I haven't noticed any difference so far.

Thats identical for me: works fine, see no difference.

@unphysicalix: 3.27.0-7 is already without Elsint.

Electron 13.6.8-2 is out, I will have update but before I have some work to do on the PKGBUILD
in order to ease its maintenance. It will probably be ready late on Sunday...

Till then, I can put Eslint back if something goes wrong without it. On my system,
I haven't noticed any difference so far.

@etaboon: hi,

I am happy to test a version without eslint. I am just not sure: is the version scratch3 v3.27.0-7 already one without eslint? Or do I have to do and compile that myself?

[Edit: +1]
@unphysicalix: hi,
I'm ok to flag the package out-of-date when a new version of Electron is out, no problem!
This time I was late because poor internet connection: the new PKGBUILD had already been ready for some time.
Thanks to a neighbor, I could push the commit today.

--> Finally I think I've found a way to use Arch Linux's electron13 instead of github's one.
But I can't make a new release just now and for a few days. :(

--> I also found a way to perhaps save some more bandwidth. As we don't use Eslint to build the app,
I think we can safely drop Eslint dependencies (in package.json). I've quickly tested a build without it and
it doesn't seem to be any differences in the output. And the node_modules size dir decreased significantly
(-40 in number of folders, -17% in size: -176 MB). Would you like to test such a version?

hi @etaboon,

They could have made it more flexible. For instance in using a config file which would store the path to the installed library (not so easy though when it needs adaptation to other platforms).

thanks for the elaborate answer. Using these arguments it fairly responsible to use your own electron. As soon as the upstream developer think of these issues, it might be time to reconsider using a system-wide installation.

anyway, is it ok to flag the package out-of-date in case like this today, that there was a new version of electron13 out? I'm not sure how to automatically do this, it just came to my mind when I saw the update...

Cheers, Tobias

@unphysicalix: hi,

original question: is it impossible to use the system-wide installed electron13 ?
or is it just "common behaviour" to package your own electron to make your piece of software more portable?

About 'common behavior', I don't know, I'm just not a developer. Here is however what I think of this:

It's entirely possible to use the system-wide installed electron13 in certain circumstances.
It will depend on the features of the app and how the dev will code them.

Besides the first packager of Scratch3 proposed to install Scratch3 in this way
and the app was running fine. However there was the issue of not being able to load other sprites,
load other backgrounds and load other sounds from the library. Why?

The app needs to know the location of the library. The devs choose an easy way to do so,
they just concatenate the application path with the string '/resources/static/assets/'.
Then, when you use the system-wide Electron app, the app will look into the folder
/usr/share/electron13/resources/static/assets/, which doesn't exist of course,
instead of the path of installed app: /opt/scratch3/resources/static/assets/.

They could have made it more flexible. For instance in using a config file which would store
the path to the installed library (not so easy though when it needs adaptation to other platforms).

The use of system-wide installed electron is moreover not necessarily desirable.
In packaging the app with one's chosen and tested version of Electron has one big advantage:
the warranty of delivering an app that won't be broken by a new Electron version (with possible regressions)
after a system update. Remember Scratch3 stopped loading when Electron version reached the 12 series?

Hope all this answers to your question. There are other aspects I could develop but it would make the answer very long.