Old and documented default is 0, tho the implementation changed at some
point to 1 in it's default config. As such explicitly set it to 0 so it
stays as is independent of stylistic version.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Up to now `eslint-plugin-brace-rules` was used to enforce a common brace
style for JavaScript code. This plugin was however updated the last time
over 9 years ago and will be incompatible with ESLint v10, as that
[removes `context.getSourceCode()`][1], the plugin relies on.
To keep the eslint config working with ESLint v10, this replaces
`eslint-plugin-brace-rules` with the [`@stylistic/brace-style`][2] rule
from `@stylistic/eslint-plugin`, a package we already use.
While `@stylistic/brace-style` doesn't offer an option to format braces
in exactly the same way as before, the "allman" style seems to be the
one closest to the existing code.
[1]: https://eslint.org/blog/2025/11/eslint-v10.0.0-alpha.0-released/#removed-deprecated-rule-context-members
[2]: https://eslint.style/rules/brace-style
After Stan suggesting change in a review comment just enable the rule
'keyword-spacing' [1] and fix violations so this is no longer a topic in
spirit of #7812.
[1] https://eslint.style/rules/keyword-spacing
Ref: #7245
Ref: #7812
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
This rules can all be enabled without any code changes, meaning we
already follow them properly.
Ref: #8068
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Disabled rules are the same as not listed rules of which there are many,
keep them out of the config.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
They way the project is structured this isn't really usable for now but
might change with move to ESM modules.
See: https://eslint.org/docs/latest/rules/no-unused-vars
Ref: #8068
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
They way the project is structured this isn't really usable for now but
might change with move to ESM modules.
See: https://eslint.org/docs/latest/rules/no-undef
Ref: #8068
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Eslint maintains a list of rules it recommends, split them into own
section for easy identification.
Further sort the rules and don't use magic values for severity.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
The rule 'no-negated-in-lhs' was deprecated in eslint 3 [1], replace it
according to recommendation with 'no-unsafe-negation' and enable all
extras as our code already conforms.
[1] https://eslint.org/docs/latest/rules/no-negated-in-lhs.html
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
During the eslint 8 cycle the formatting rules were split out [1],
deprecating the corresponding rules in core.
This replaces all rules that where moved to @stylistic/eslint-plugin [2]
and accounts for the difference in the indenting rule behaviour.
To allow the pre-commit import hack to continue to work with the
stylisitc plugin for a recent nodejs version to be used.
[1] https://eslint.org/blog/2023/10/deprecating-formatting-rules/
[2] https://eslint.style/packages/default
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
- With modules JavaScript code can be split up into multiple files. We
already implemented such a mechanism (`Engine.LoadLibrary`) in
multiple parts of the engine. The advantage of using modules is
that it's standart (JS-devs are familiar with it) and it doesn't
has to be implemented multiple times.
Note that `Engine.LoadLibrary` loads all files in a directory
while the new `import` only loads one file.
- With modules seemingly global variables are local to that
script/module. We already implemented such a mechanism
(`ScriptInterface::LoadScript`).
This replaces the old arclint eslint setup 1:1 rule wise, only porting
the configuration to a format recent eslint can read.
Further remove the arclint setup as it is no longer of use.
Thanks to Stan for reviewing all needed fixes to Javascript code to
allow for adding this without compromises.
Fixes: #7812
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
