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
I simply cannot deal with multi-line trinary expressions where the
two "branches" don't align, so add an exception for them.
And while the strict 4-line indent for objects is growing on me for
"regular" objects:
let foo = new Foo({
bar: 42,
baz: 'bam'
});
I do prefer the current style of compact braces and aligned properties
for object lists:
let entries = [
{ name: 'foo',
visible: true },
{ name: 'bar',
halign: Gtk.Align.START }
];
So allow the latter style as well, at least for the time being.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
When using arrow functions, we only omit the braces when we are using
the return value:
this.get_children().filter(w => w.visible);
When braces are used, eslint by default enforces line breaks, but
there are cases where the expression is hardly less concise than
the above:
this.get_children().forEach(w => { w.destroy(); });
So change the default to allow this.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
All variables should be in camelCase, so configure the corresponding
rule to enforce this. Exempt properties for now, to accommodate the
existing practice of using C-style underscore names for construct
properties of introspected objects.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
gjs started to run eslint during its CI a while ago, so there is an
existing rules set we can use as a starting point for our own setup.
As we will adapt those rules to our code base, we don't want those
changes to make it harder to synchronize the copy with future gjs
changes, so include the rules from a separate file rather than using
the configuration directly.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
When destructuring multiple return values, we often use trailing commas
to indicate that there are additional elements that we are ignoring.
There isn't anything inherently wrong with that, but it's a style that's
too confusing for eslint - on the one hand we require a space after a
comma, on the other hand we require no space before closing brackets.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
String concatenation is considered bad style after ES6 added
template strings. The latter is the replacement we generally
want, except where the aforementioned xgettext bug would trip
over the backtick/slash combination.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
While we have some style inconsistencies - mostly regarding split lines,
i.e. aligning to the first arguments vs. a four-space indent - there are
a couple of places where the spacing is simply wrong. Fix those.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
We currently use a consistent style of not adding spaces in catch
clauses, however that's inconsistent with the style we use for any
other statement. There's not really a good reason to stick with it,
so switch to the style gjs/eslint default to.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
Florian Müllner
Tomasz Gąsior
Gun Chleoc
Matej Urbančič