In the latest versions of ESLint, more and more formatting rules were
removed or declared deprecated. These rules have been integrated into
the new Stylistic package (https://eslint.style/guide/why) and expanded.
Stylistic acts as a better formatter for JavaScript as Prettier.
With this PR there are many changes that make the code more uniform, but
it may be difficult to review due to the large amount. Even if I have no
worries about the changes, perhaps this would be something for the
release after next.
Let me know what you think.
- order (external first)
- remove superfluous file extensions
- new line after imports
- deconstruct (only one time (in `check_config.js`))
- fix path (only one time (in `global-setup.js`))
We have used it inconsistently till now. Template literals are more
modern and easier to maintain in my opinion.
Because that's a large amount of changes, here's a way to reproduce it:
I added the rule `"prefer-template": "error"` to the `.eslintrc.json`
and did an autofix. Since this caused a new problem in line 409 of
`newsfeed.js`, I reversed it in that line and also removed the rule from
the eslint config file.
The rule is described here:
https://eslint.org/docs/latest/rules/prefer-template
Note: I've played around with some other linter rules as well, and some
seem to point to some specific, non-cosmetic, issues. But before I dive
even deeper and then introduce even bigger and hardly understandable
changes at once, I thought I'd start with this simple cosmetic rule.
by running calendar and newsfeed tests last.
Additional change: allow unit tests to run parallel
This is no fix of the real issue of calendar and newsfeed tests but I
moved them to the end of the tests so other tests are not failing
anymore.
There are coming follow up PR's for the real fixes (when I find the
culprits).
With these change we can stay with the async changes done by @rejas and
https://github.com/MichMich/MagicMirror/pull/3060 is obsolete.
Refactored the mock data generation for the tests so we can use plain
JSON files for the data and read it in a more general way.
Comments welcome!
Co-authored-by: veeck <michael@veeck.de>
