Updating Build Tools for M1 Macs

[daveseah]

While reinstalling GEMSTEP on M1 and Intel macs that had previously not had any dev environment on them, I have encountered several showstopping install bugs while following the instructions on the Wiki and in the install-helper.sh script.

This issue will capture the errors, and suggest a fix. Probably better to do this sooner than later, as the issue may effect other people attempting to install the software to evaluate it.

[daveseah]

M1/SONOMA: ERRORS NOTED

• There is a more stringent update required for running NodeJS on M1. Version 18 of Node seems to be the minimum version to target, as this forces several updates with dependent packages (experimental M1 support was only added in v15, with full support happening in v16).
• nvm install v14.18.1 failed on M1 mac because file not found; may have been deprecated (it’s EOL) but also the binaries and changelog on the repo seems to be down! Running nvm install v14 to grab the latest v14 release seemed to work (it grabbed v14.21.3), but it is compiling from source and took many long minutes.
• The current version of lerna (7.3) does not support Node v14 at all. Choice is to update Node itself, or use npm install -g lerna@6.4.1
• Alternative: I’m doing is using v18.16.0, which suffers one error: webpack is using old digital envelope routine because the algorihm is MD4, no longer supported. This post has a few solutions...

[daveseah]

INTEL/BIG SUR: ERRORS NOTED

• Installation using v14.18.1 worked fine, following install script. Compilation worked fine.
• Error running GEMSRV with npm run gem due to the yaml and yaml-loader libraries introducing javascript syntax ?. that is not supported in the v14 runtime. This is a problem with yaml-loader changing the version of yaml it uses without changing its version number. This is a webpack module that allows for direct require of .yaml files as javascript objects, used in codex.ts (help system)

  ERROR in /help/codex-events-yaml: Module build failed (from gsgo/node_modules/yaml-loader/index.js):
  gsgo/node_modules/yaml-loader/node_modules/yaml/dist/compose/composer.js:33
  if (prelude[i + 1]?.[0] != '#')

[daveseah]

I'm creating a new branch dev-sri/build-update-2023 to do an update of node under the following conditions with the minimal changes needed to reliably get the repo to run without a lot of fuss.

• [ ] latest LTS version of Node
• [ ] M1 and Intel

At some point we need to update the webpack version from v4 to v5, as v4 is quite old. This includes the other plugins it is dependent on, which are many. As v5 has breaking configuration changes this is a tedious and meticulous task.

[dsriseah]

There is an ongoing issue importing libraries when you see this when starting up: Can't access exports in various PIXIJS related modules: Can't find module:

These are probably webpack issues, possibly related to pixijs having changed their library structure in older versions of pixijs which breaks compatibility. These are all related to es modules.

I could have sworn I fixed this before, but it's not in my current build or any past build I can find as of this writing. Continuing to look.

[dsriseah]

Searching for "webpack 4 pixijs" shows this: https://github.com/pixijs/pixijs/issues/8554#issuecomment-1237913225

[dsriseah]

Applying this to wp.base.config

        {
          test: /\.mjs$/,
          include: /node_modules/,
          type: 'javascript/auto'
        },

Fixes all the named export issues. However, the module-not-found errors still need resolution.

Speculation: the mjs extension is a node-js only file extension that shouldn't be an import in the pixijs library itself as it's a client-side library. I suspect this is a bug or oversight in the lib that is masked by webpack 5, which has automatic mjs support according to the comments. We are still using webpack 4.

[dsriseah]

To resolve module not found 'clipboard' in prism_extended.js, declaring it as external in wp.pack.webapp.js as follows:

    externals: {
      clipboard: 'ClipboardJS'
    },

resolves it. This is a script in vendor that shouldn't be processed by webpack, though I'm not sure why it is being processed now when it hasn't worked that way during active GEMSTEP development.

[daveseah]

Apparently this branch hasn't been functioning because it wasn't as I though merged with the latest dev, but with another older dev update with a similar auto-generated merge name.

The latest dev as of this check does have the extra checks and fixes I put in, so I am closing this issue and deleting its associated branch build-updates-2023