The coding style of using double quotes for translatable strings
and single quotes otherwise is unnecessarily complex and cannot
be enforced with an eslint rule.
Simply use single quotes consistently for all strings.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/57
Instead of keeping the first property on the same line as the opening
brace and aligning the properties, use a four-space indent. This brings
us closer to gjs' coding style, and as a bonus helps keeping lines in
the soft 80 character limit.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/57
Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.
We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.
So just omit braces consistently as mandated by gjs' coding style.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/57
We picked those up from Polari, which had those for
- object arrays:
let foo = [
{ bar: 42,
quz: true },
{ bar: 23,
quz: false }
];
- "enums":
let Options = {
ONE: 0,
TWO: 1,
THREE: 2
};
We don't have either of those, so drop the rules to minimise divergence
with gjs.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/57
Commit messages should include the full URL to an issue or merge
request to keep associated information easily available in future
log digging.
Jonas came up with a script to enforce that policy for mutter and
gnome-shell. It's an excellent idea, so adopt it here as well.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/52
It doesn't make too much sense to declare parts of the existing style
"legacy", but then enforce it via CI. To allow for a gradual switch,
generate a report with all issues that eslint considers errors in both
configurations.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
More testing is always good, and the static analysis that eslint
provides goes well beyond what js60 offers, so run it as part of
the CI.
This will also ensure that new contributions comply with the style
rules we have set up.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
Unused variables or arguments can indicate bugs, but they can also
help document the code, in particular in case of signal handlers
and destructuring.
Account for this by keeping the error, but set up patterns that allow
us to opt out of if for individual variables/arguments. For arguments
we pick a '_' prefix, while for variables we go with a suffix instead,
to not accidentally exempt private module-scope variables.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
Regarding coding style, gjs is moving in a direction that departs quite
significantly from the established style, in particular when indenting
multi-line array/object literals or method arguments:
Currently we are keeping those elements aligned, while the gjs rules now
expect them to use the regular 4-space indentation.
There are certainly good arguments that can be made for that move - it's
much less prone to leading to overly-long lines, and matches popluar JS
styles elsewhere. But switching coding style implies large diffs which
interfere with git-blame and friends, so in order to allow for a more
gradual change, add a separate set of "legacy" rules that match more
closely the style we would expect up to now.
It also disables the rules for quotes and template strings - the former
because we cannot match the current style to use double-quotes for
translatable strings and single-quotes otherwise, the latter because
template strings are still relatively new, so we haven't adopted them
yet.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
That function will eventually be replaced with decorators, and we don't
want to re-indent all GObject classes when that happens, so allow class
declarations with no indent:
GObject.registerClass(
class Foo extends GObject.Object {
});
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
