which needs no api key.
I think this is a better choice than the old one because new users which
use this config as starting point will now see weather data instead of
`loading...`
Mastermerge label wasnt checked correctly, this PR should hopefully
fixes it for good
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Hey!
This PR should change the behaviour of starting fullDay events that last
several days. The goal was to change the behavior of the "Starting
today, ends T" (T=Tomorrow) event, so it should show how many days it
will occur from the first day on
Before situation:
a fullDay event that started 'today' and ends several days later showed
Today on the first day. The rest of the days it showed X days left.
Y => Yesterday
T => Tomorrow
Target situation with this commit:
a fullDay event that started 'today' shows 'X days left' from the first
day on and 'Today' on the last day.
---------
Co-authored-by: Veeck <github@veeck.de>
user reported problem with clock module, checking code found dependency
on suncalc library, but it is not loaded in production mode.. move
dependency
---------
Co-authored-by: veeck <michael.veeck@nebenan.de>
Fixes issue #3345.
I think I submitted this correctly, but don't do this often so let me
know if anything needs to be corrected.
---------
Co-authored-by: Veeck <github@veeck.de>
Hi, I had the case of some users who set a very small fetchinterval (10
sec for example)
in some cases, it may be that the request did not have time to complete
correctly and that the next one has already been sent (generally on
start of MM²)
I think that lock min fetchInterval to 60000 is a good idea
from forum,
https://forum.magicmirror.builders/topic/18493/node_helper-js-is-not-working
user created own config.js, did not copy the module exports line..
this caused the js/defaults.js list of modules to be processed for
node_helpers
but the physical config.js to be loaded for the web page (hard coded in
index.html)
so user modules needing node_helper didn't have that ..
this adds a warning message in npm start output to help user resolve..
took two days to debug without message
and also node-ical
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The new version of husky makes it possible to simplify the pre-commit
hook a little.
And since prettier no longer takes care of the JavaScript files in our
project, it can no longer come into conflict with ESLint while running
lint-staged. Therefore we can activate the correction of ESLint issues
here.
* Worked around several issues in the RRULE library that were causing
deleted calender events to still show, some initial and recurring events
to not show, and some event times to be off an hour. (#3291)
* Renamed variables in *calendarfetcherutils.js* to be more clear about
use of `moment` and js's `Date` class.
* Added calendar config option `forceUseCurrentTime` (default:`false`)
which will ignore overridden `Date.now` in the config in order to keep
some tests consistent.
* Added several unit tests for crossing DST in different timezones with
excluded events.
see #3358
used command: `find ./ -type f -exec perl -i -0pe
's/\/\*\s*magicmirror.*?\*\/\s*//si' {} \;`
This is a first draft, I think we should preserve some of the comments.
Notable changes in this context:
- simplification of the ESLint calls - there is no longer a combination
of two file/directory lists (one in `package.json` and one in
`.eslintignore`)
- removal of a non-existent path from the `.eslintignore`
- use shorthand declaration for GitHub repository
Normally the new plugin would also sort the scripts in the package.json
alphabetically, but I think the current order is fine, so I deactivated
it.
Is it overkill to introduce a linter plugin just for the `package.json`
files?
In other projects I have seen that such internal changes were marked
with "chore" in the changelog. That's what I've done here. These chore
changes are less interesting for "normal" users.
Please feel free to give me feedback.
#3285
Because there is so many conflit with package,
I have rewrite the code with v2.27.0-develop
For remember:
* recode: `update_helper.js` with `pm2` library
* fix: default config -> `updates` is a array
* delete: `command-exists` library (not used)
* delete: `PM2_GetList()` function (not used)
* add: check `updates.length` (prevent crash)
* add: `[PM2]` tag in log (for better visibility)
* add: `pm2` library
advantage:
* we use the pm2 library directly
* avoids weird returns from child_process.exec when requesting a json
format from pm2
* simplified the code
inconvenient:
* we have vulnerabilities with axios
240120 Fix:
* use `pm2_env.pm_cwd` instead of `pm2_env.PWD` : prevent using `pm2
restart <id> --update-env` in other directory (for enable GPU rendering
for exemple)
* resolve packages (again)
It appears that #3336 introduced a bug where a newsfeed with >1 items
would stop updating after a while (usually after `activeItem` wraps
around the end of the list). Sorry! My bad, I hadn't tested that case
well enough.
For experimenting, I sometimes work with different CSS files. I can
imagine that others do this too.
This setting for the css folder corresponds to the setting we already
have for the config folder.
When the newsfeed module has an items list of size 1, every
`updateInterval` the animation runs to transition from the active story
to itself. This is unsightly. This PR suppresses that.
To reproduce: configure newsfeed with a single news source,
`ignoreOldItems` true, a short `updateInterval` (e.g. 3000), and a
carefully-chosen small `ignoreOlderThan` lining up with the current
contents of your news source.
Removing lodash dependency by replacing merge by spread operator.
I have also split the return into two variables to make it easier to
understand what is happening.
It is basically a cosmetic thing, but has the following advantages:
1. Consistency with the official node documentation. The prefix is used
there.
2. It is easier to recognize the build-in modules.
This is a first attempt to bring additional system information into the
console (see #3328). It's certainly not yet perfect, but with the PR we
have a better basis for discussion.
I tried to keep the output small so that we get as much information as
possible in screenshots.
This is how it looks on my development system.
```bash
[03.01.2024 00:50.19.226] [INFO] System information:
### SYSTEM: manufacturer: Notebook; model: N650DU; raspberry: undefined; virtual: false
### OS: platform: linux; distro: Debian GNU/Linux; release: 12
### VERSIONS: MagicMirror: 2.27.0-develop; electron: 27.2.0; kernel: 5.10.0-20-amd64; node: 21.1.0; npm: 10.2.4; pm2: 5.3.0; docker: 20.10.24+dfsg1
```
Why is it still a draft:
- [x] I have doubts that utils.js is the right place for the function. What do you think?
=> Update: As long as there is no better idea, it stays there.
- [x] Instead of working through all wishes you expressed in the issue #3328, I only implemented what was easy to achieve. And wanted to hear what you think about this approach.
=> Update: Some added. Of course, more information could be added later, as soon as experience has been gained in productive use.
- [x] I don't quite like the introductory line ("The following lines provide information..."). Should I perhaps simply replace it with "System information:"?
=> Update: Changed to "System information:"
[Here](https://github.com/sebhildebrandt/systeminformation#function-reference-and-os-support) you can see what information we could easily add with the systeminformation package.
It would be interesting how the raspberry field is filled on a raspi system and with docker there should be another line, but I can't easily test that now.
