Mk/Uses/electron.mk and companion scripts: Helper makefile and scripts for easily porting Electron-based applications

[tagattie]

Summary

I would like to propose a new electron.mk and companion scripts for making it easier to port Electron-based applications.

There are a number of obstacles in porting Electron-based appications, namely:

• Need to adapt to different node package managers used in a project (npm, yarn, and pnpm)
  
  Different package managers have different commands and options. With electron.mk, porters don't have to worry about those differences using USE_ELECTRON=npm feature.

• Need to create an archive of necessary node modules and host the file somewhere online
  
  An Electron-based project usually tries to install npm install command during the build phase. We can't allow this because npm install involves network access. So we had to pre-generate an archive for necessary node modules and host it somewhere online. electron.mk eliminates the necessity by locally generating the distfile for node modules on-the-fly at a host building the port during the fetch phase.

• Need to adapt to different package builders used (electron-builder, electron-packager, and electron-forge)
  
  Different package builders have different commands and options. With electron.mk, porters don't have to worry about those differences using USE_ELECTRON=build feature.

In sumary, electron.mk hides the complexities of porting Electron-based applications under the hood with USES=electron and USE_ELECTRON features.

Test Plan

Examples of how electron.mk can be used at the following repository: (https://github.com/tagattie/FreeBSD-Electron)

I am going to add the following two ports, both of which uses the proposed electron.mk and listed in Wanted Ports on the Wiki, after this revision has landed:

• deskutils/joplin-desktop (https://github.com/tagattie/FreeBSD-Electron/tree/master/deskutils/joplin-desktop)
• net-im/teams (https://github.com/tagattie/FreeBSD-Electron/tree/master/net-im/teams)

Note: Those ports are not included in thie review.

[arrowd]

Mk/Uses/electron.mk

75

Do we really need extract? If a port uses prefetch can't we conclude that it also would extract the prefetched modules?

97

Typo "packageing".

111

I'm not a big fan of running arbitrary shell commands with FOO!=... syntax.

How about this - we make NPM_VER a user-facing knob that the port should always define. Then we put "packageManager" : "${NPM_VER}" into package.json during the patch stage, effectively making it controllable via Makefile, rather than figuring it out from package.json?

124

Same here, how about enforcing these versions from the Makefile instead of reading them from upstream sources?

151

Just a little bikeshedding:

_ELECTRON_CMD_BASE=...
_ELECTRON_PORT_BASE=...

and _NODEJS_PORT. Both kde.mk and qt.mk name these things PORT, so it would seem more consistent to me.

585

Typo "generates".

[tagattie]

Mk/Uses/electron.mk

75

Most Electron-based ports likely use both prefetch and extract features. However, Node.js-based projects give developers great flexibility and there may be cases where prefetch and/or extract features cannot fully address the projects' requirements. In such cases, you might want to write custom prefetch target and only use the extract feature. Conversely, there may also be cases where only prefetch is used.

111

I agree that FOO!=... is not a good practice.

I have made NPM_VER a user-definable variable, but that does not mean a porter can freely decide its value. It is user-definable in the sense that a porter can supplement it when project developers fail to define packageManager in package.json.

A port should use a package manager of the version specified in package.json to avoid unexpected errors as much as possible.

124

Same as above, enforcing the Electron version to a one other than specified in package.json will not work. Because electron node module tries to download binary distribution files of the version specified in package.json and it will break builds with poudriere.

151

Thank you for the suggestion. It is good keep consistency throughout the ports framwork. I would amend the variables accordingly.

[tagattie]

Rebased after electron34 removal.

In addition, add some check for directory/executable existence to avoid potential errors.

[tagattie]

It seems nobody is uncomfortable with the proposed addition of .mk/companion scripts.

@arrowd, thanks for the comments. I think I have answered them with in-line comments.

Assuming there are no grave issues with the current patch, I am going to commit the patch within a couple of days (with implicit approval from portmgr).