Jest was in the plugin array of the ESLint configuration, but no rules
were enabled. So ESLint hasn't checked any Jest rules yet.
So I activated the recommended Jest rules and added a few more. Then I
fixed the issues (mostly automatically). I have deactivated the rules
"jest/expect-expect" and "jest/no-done-callback" for the time being, as
they would have entailed major changes. I didn't want to make the PR too
big.
I'm not a Jest expert, but the changes so far look good to me. What do
you think of that @khassel? 🙂
- Remove "prettier" from plugin array, because it's already enabled by
"plugin:prettier/recommended"
- Remove "jsdoc" from plugin array, because it's already enabled by
"plugin:jsdoc/recommended"
- Enable recommended import rules
- Add two additional import rules
Note: To avoid overloading this PR I'll tackle the jest part with
another PR after this one has been dealt with.
Fixes: #3256
BUT.. the testcase is inconclusive.. as the code FAILS without the fix,
BUT somehow RETURNS 0 entries..
in real life run the node helper fails, and all calendar processing
stops.
Hello and thank you for wanting to contribute to the MagicMirror²
project
**Please make sure that you have followed these 4 rules before
submitting your Pull Request:**
> 1. Base your pull requests against the `develop` branch.
> 2. Include these infos in the description:
>
> - Does the pull request solve a **related** issue?
> - If so, can you reference the issue like this `Fixes
#<issue_number>`?
> - What does the pull request accomplish? Use a list if needed.
> - If it includes major visual changes please add screenshots.
>
> 3. Please run `npm run lint:prettier` before submitting so that
> style issues are fixed.
> 4. Don't forget to add an entry about your changes to
> the CHANGELOG.md file.
**Note**: Sometimes the development moves very fast. It is highly
recommended that you update your branch of `develop` before creating a
pull request to send us your changes. This makes everyone's lives
easier (including yours) and helps us out on the development team.
Thanks again and have a nice day!
Hello and thank you for wanting to contribute to the MagicMirror²
project
**Please make sure that you have followed these 4 rules before
submitting your Pull Request:**
> 1. Base your pull requests against the `develop` branch.
DONE ;D
> 2. Include these infos in the description:
> - Does the pull request solve a **related** issue?
NO
> - What does the pull request accomplish? Use a list if needed.
For calendar entries containing a year (e.g. DOB) in the title, the age
can be calculated.
Example before:
after:
Achieved by adding a new keyword `transform` to customEvents
```
customEvents: [
{keyword: 'Geburtstag', symbol: 'birthday-cake', color: 'Gold', transform: { search: '^([^\']*) \'(\\d{4})$' , replace: '$1 ($2.)', yearmatchgroup: 2}},
{keyword: 'in Hamburg', transform: { search: ' in Hamburg$' , replace: ''}}
],
```
and therewith obsoleting `titleReplace`; a backward compatibility part
is already included.
If `yearmatchgroup` is unset, behaviour is as in previous code (some
additions to which RegExes are accepted, though)
If `yearmatchgroup` is set, it is considered the RegEx match group id,
which will be used for calculating the age.
> - If it includes major visual changes please add screenshots.
NO
> 3. Please run `npm run lint:prettier` before submitting so that style
issues are fixed.
DONE
> 4. Don't forget to add an entry about your changes to the CHANGELOG.md
file.
DONE
> Thanks again and have a nice day!
You too and if any questions, feel free to let me know.
---------
Co-authored-by: veeck <michael.veeck@nebenan.de>
Fixes#3227
and also
- removes unused code
- de-duplicates code fragments
- fixes typos
- inlines code
- adds more weather util tests
@martingron and @Justheretoreportanissue would you be so kind to check
if I didnt mess anything up?
Hi,
Just because, i never try to code a test
I purpose to supervise this work
After, perhaps it is not necessary to integrate it in develop branch.
It's up to you to decide
Hello,
This pull request allows you to add a class to the tr of the event
sought in customEvents. You must enter the class with the "eventClass"
option.
---------
Co-authored-by: TeddyStarinvest <teddy.payet@starinvest.com>
related to #2649
I was able to move to internal fetch and all tests seems fine so far.
But we have one problem with the calendar module. In the docs we have
several authentication methods and one of them is `digest`. For this we
used `digest-fetch` which needs `node-fetch` (this is not so clear from
code but I was not able to get it working).
So we have 3 options:
- remove `digest` as authentication method for calendar module (this is
what this PR does at the moment)
- find an alternative npm package or implement the digest stuff
ourselves
- use `digest-fetch` and `node-fetch` for calendar module (so they would
remain as dependencies in `package.json`)
Opinions? @KristjanESPERANTO @rejas @sdetweil @MichMich
Adding date to the clock module when displayType is "analog" and
"showDate" is true. The setting in analogShowDate is respected.
Fixes#3100
---------
Co-authored-by: Michael Teeuw <michael@xonaymedia.nl>
Co-authored-by: Veeck <github@veeck.de>
Fixes#3095.
Param `hideOngoing` is by default set to `false`, but the event
filtering handles `full day` & `non-full day` events inconsistently. For
`non-full day` _ongoing_ and _upcoming_ events are returned, while for
`full day` only _upcoming_ events where returned.
While waiting for the easterbunny I cleaned up some bad coding practice
:-)
Very open for comments especially regarding the places I commented
myself...
---------
Co-authored-by: veeck <michael@veeck.de>
Refactored some methods in calendar module:
- move methods into own file
- dont call shorten method from titelTransform because why? just call
them after each other.
- added tests for util methods
- cleaned up other tests
---------
Co-authored-by: veeck <michael@veeck.de>
Updated sunrise/sunset times to display user-requested timezone rather
than system timezone.
Note: rebase of #3069 against develop rather than master
Co-authored-by: Veeck <github@veeck.de>
While looking at https://github.com/MichMich/MagicMirror/pull/3070 I
noticed that the weather and clock module do some formatTime stuff, so
why not use a common function for that?
---------
Co-authored-by: veeck <michael@veeck.de>
- 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.
Hi,
want to include a birthday calendar to my mirror which shows upcoming
birthdays and as a reminder birthdays of the last two days.
I used
[MMM-CalendarExt2](https://github.com/MMM-CalendarExt2/MMM-CalendarExt2)
for this job in the past but the module is not supported any more and
very complicated to configure.
I managed to style the default calendar module to my needs but what i am
missing is to display already past events within a configurable time
range.
I included the translations of "YESTERDAY" and "DAYBEFOREYESTERDAY" to
all translation files and modified the code to accept a new option
`pastDaysCount` which controls of how many days past events should be
displayed.
---------
Co-authored-by: Veeck <github@veeck.de>
Percentage should be always rounded so that we dont get something like
"47.0000000001 %"
Some small typo and naming fixes also while I am here
---------
Co-authored-by: veeck <michael@veeck.de>
1. Update `stylelint` dependencies
- As of stylelint v15, we do not need `stylelint-config-prettier`
anymore:
https://github.com/prettier/stylelint-config-prettier/releases/tag/v9.0.5
2. Switch to `stylelint-config-standard`:
`stylelint-prettier/recommended` has not been updated for a long time
and still needs the old `stylelint-config-prettier`
3. Handle new `stylelint` issues
They weren't applied to wrong classnames, this PR fixes that and also
expands the weather util tests
---------
Co-authored-by: veeck <michael@veeck.de>
Fixes#2953
This is an attempt to fix the issue with precipitation amount and
percentage mixup. I have created a separate
`precipitationPercentage`-variable where the probability of rain can be
stored.
The config options now has the old `showPrecipitationAmount` in addition
to a new setting: `showPrecipitationProbability` (shows the likelihood
of rain).
<details>
<summary>Examples</summary>
### Yr
I tested the Yr weather provider for a Norwegian city Bergen that has a
lot of rain. I have removed properties that are irrelevant for this demo
from the config-samples below.
Config:
```js
{
module: "weather",
config: {
weatherProvider: "yr",
type: "current",
showPrecipitationAmount: true,
showPrecipitationProbability: true
}
},
{
module: "weather",
config: {
weatherProvider: "yr",
type: "hourly",
showPrecipitationAmount: true,
showPrecipitationProbability: true
}
},
{
module: "weather",
config: {
weatherProvider: "yr",
type: "daily",
showPrecipitationAmount: true,
showPrecipitationProbability: true
}
}
```
Result:<br/>
<img width="444" alt="screenshot"
src="https://user-images.githubusercontent.com/34011212/216775423-4e37345c-f915-47e5-8551-7c544ebd24b1.png">
</details>
---------
Co-authored-by: Magnus Marthinsen <magmar@online.no>
Co-authored-by: Veeck <github@veeck.de>
see discussion here:
https://github.com/MichMich/MagicMirror/pull/2991#issuecomment-1376372720
I still see a need for updating `master` in special cases (e.g. correct
errors in README.md which would otherwise be present up to 3 month until
next release) so with this PR **only for MagicMirror repo** and **only
for `master` branch** updatenotifications are only triggered if at least
one of the new commits has a tag.
May @MichMich must decide if this is wanted.
Co-authored-by: Veeck <github@veeck.de>
Fixes#3019
The previous implementation had the arrow pointing in to the wind. When
the wind blows from the north (0 degrees), the arrow should point
straight down. In other words, no rotation of the arrow-down symbol.
When the wind blows from the south (180 degrees), the arrow should point
straight up (I.e. the arrow down symbol rotated 180 degrees).
Co-authored-by: Magnus Marthinsen <magmar@online.no>
Symbols provided in customEvents don't get the "fas fa-fw fa-" prefix,
which according to the docs they should. This fixes that.
Hello and thank you for wanting to contribute to the MagicMirror²
project
**Please make sure that you have followed these 4 rules before
submitting your Pull Request:**
> 1. Base your pull requests against the `develop` branch.
>
> 2. Include these infos in the description:
>
> - Does the pull request solve a **related** issue?
> - If so, can you reference the issue like this `Fixes
#<issue_number>`?
> - What does the pull request accomplish? Use a list if needed.
> - If it includes major visual changes please add screenshots.
>
> 3. Please run `npm run lint:prettier` before submitting so that
> style issues are fixed.
>
> 4. Don't forget to add an entry about your changes to
> the CHANGELOG.md file.
**Note**: Sometimes the development moves very fast. It is highly
recommended that you update your branch of `develop` before creating a
pull request to send us your changes. This makes everyone's lives
easier (including yours) and helps us out on the development team.
Thanks again and have a nice day!
Co-authored-by: veeck <michael@veeck.de>
