NPM assumes quite strongly that it manages the project as a
whole and its package/lock files are located in the project
root.
While we somehow managed to keep the npm tooling in a subfolder,
this comes at the cost of breaking imports of additional modules.
This will become relevant when we update eslint to a supported
version, as we want to keep using the `junit` formatter in CI,
which has now been split out into a separate module.
So bite the bullet and make the node_modules folder available in
the project root.
On the plus side, having the node_modules folder in the project
root allows language servers in IDEs/editors to pick it up.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/431>
Both changes in the config (like new/changes rules) and the eslint wrapper
(like updating to eslint 9.x) could require changes here, and therefore
require a conscious update rather than randomly breaking the CI.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/431>
Both the .json and .yml config formats are deprecated in favor
of flat configs exported from eslint.config.js files.
The good news is that gjs' config is now available as a shared
config from the `eslint-config-gnome` package in World/javascript,
so we no longer have to copy the entire thing.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/408>
The script is a small wrapper around the `ci-run-eslint` package
from World/javascript, which is a generalized and improved version
of the .gitlab-ci/run-eslint script from gnome-shell.
It only requires `npm` to be available, so it simplifies running
eslint locally quite a lot
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/408>
