Re-enable eslint test

[JRivrain]

1. This reverts commit a9444d9.

Eslint needs an older version of ajv, otherwise fails with "NOT SUPPORTED: option missingRefs.(...)"
because this was changed in ajv v8,
see https://progress.opensuse.org/issues/192169#note-6

2 - Re-enable eslint test

See https://progress.opensuse.org/issues/192169 and
#2879

We also need to re-create the package-lock file to avoid a mistmatch,
since we started using npm clean-install instead of npm install

[okurz]

why should we reintroduce the deprecation warning? Or are you just trying out effects in GHA?

[JRivrain]

why should we reintroduce the deprecation warning? Or are you just trying out effects in GHA?

Partially yes, trying out effects but also, forcing using ajv v8 seems to be causing this:

NOT SUPPORTED: option missingRefs. Pass empty schema with $id that should be ignored to ajv.addSchema.

Oops! Something went wrong! :(

ESLint: 9.39.1

TypeError: Cannot set properties of undefined (setting 'defaultMeta')
    at ajvOrig (/home/runner/work/qem-dashboard/qem-dashboard/node_modules/@eslint/eslintrc/dist/eslintrc-universal.cjs:385:27)
    at Object.<anonymous> (/home/runner/work/qem-dashboard/qem-dashboard/node_modules/@eslint/eslintrc/dist/eslintrc-universal.cjs:740:13)
    at Module._compile (node:internal/modules/cjs/loader:1706:14)
    at Object..js (node:internal/modules/cjs/loader:1839:10)
    at Module.load (node:internal/modules/cjs/loader:1441:32)
    at Function._load (node:internal/modules/cjs/loader:1263:12)
    at TracingChannel.traceSync (node:diagnostics_channel:328:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:237:24)
    at Module.require (node:internal/modules/cjs/loader:1463:12)
    at require (node:internal/modules/helpers:147:16)

There is probably another way to get rid of these deprecation warnings, but for now this allows to re-enable the eslint test, which is passing now.

[kalikiana]

"node_modules/eslint": {                                                      
      "version": "9.39.2",                                                        
      "resolved": "https://registry.npmjs.org/eslint/-/eslint-9.39.2.tgz",        
      "integrity": "sha512-LEyamqS7W5HB3ujJyvi0HQK/dtVINZvd5mAAp9eT5S/ujByGjiZLCzP
cHVzuXbpJDJF/cxwHlfceVUDZ2lnSTw==",                                               
      "license": "MIT",                                                           
      "dependencies": {                                                           
        [...]                                        
        "ajv": "^6.12.4",

^^ Even the next point release of eslint seems to require the old ajv.

[kalikiana]

Following comments from the upstream issue eslint/eslint#19369 leads me to nodejs/node#56632 which says the deprecation warning is being removed npm itself

[okurz]

You explain well why GHA might need the revert but why do other locations need to be reverted as well? And please comment why you think it's ok to revert 5ff9b9f as that one was done like it was done with a convincing reason. Maybe just change that in .github/workflows/ and leave the rest as is?

[JRivrain]

You explain well why GHA might need the revert but why do other locations need to be reverted as well? And please comment why you think it's ok to revert 5ff9b9f as that one was done like it was done with a convincing reason. Maybe just change that in .github/workflows/ and leave the rest as is?

Simply put, the workflow was passing before that commit that I don't fully understand, so it looks like a reasonable approach to roll it back until we understand why this happens, so the workflow can be back in service immediately, then eventually re-apply 5ff9b9f. Or, I can take more time to try things, up to you.

[kalikiana]

Simply put, the workflow was passing before that commit that I don't fully understand, so it looks like a reasonable approach to roll it back until we understand why this happens

Because you're not committing a necessary change to package-lock.json. Note where it says

npm error npm ci can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with npm install before continuing.

[perlpunk]

Conflicts need to be resolved.
I' wondering a bit about the huge amount of deleted lines in package-lock.json, but don't know enough about npm to say if this is fine.

[JRivrain]

Conflicts need to be resolved. I' wondering a bit about the huge amount of deleted lines in package-lock.json, but don't know enough about npm to say if this is fine.

I resolved the conflicts in package-lock by just running npm install on top of the latest one available in the repo. it seems like last time the package-lock file had not been re-generated for a while, hence the huge amount of modified lines. Now it looks like a lot less drastic change,

[okurz]

@JRivrain All commits and their content looks fine. Care to remove the "WIP" in the PR title?

[mergify]

This pull request, with head sha d0a3c456365749c82a05d8278e7b08292bc3fcf4, has been successfully merged with fast-forward by Mergify.

This pull request will be automatically closed by GitHub.

As soon as GitHub detects that the sha d0a3c456365749c82a05d8278e7b08292bc3fcf4 is part of the main branch, it will mark this pull request as merged.

It is possible for this pull request to remain open if this detection does not happen, this usually happens when a force-push is done on this branch revert-a9444d9, this means GitHub will fail to detect the merge.