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.
Added my (modified) updater main core into updatenotification default
module
Missing: callback display in MM² (i will code it after)
new part of configuration added:
```
updates: [
// array of module update commands
{
// with embed npm script
"MMM-Test": "npm run update"
},
{
// with "complex" process
"MMM-OtherSample": "rm -rf package-lock.json && git reset --hard && git pull && npm install"
},
{
// with git pull && npm install
"MMM-OtherSample2": "git pull && npm install"
},
{
// with a simple git pull
"MMM-OtherSample3": "git pull"
}
],
updateTimeout: 2 * 60 * 1000, // max update duration
updateAutorestart: false // autoRestart MM when update done ?
```
@khassel: i need your help
I don't use docker, maybe you can help me for this:
How can i check if MM² is running inside a docker ? (from MM² main core)
Actually, I check if we use pm2 or not.
I have to check if docker is used or not too
last time you tell me: "you can't use updater with docker", so I want to
check and deny any update if docker used
---------
Co-authored-by: bugsounet <bugsounet@bugsounet.fr>
... but e.g. a version tag
fixes#3130
This happens e.g. in my docker image where I use the version tag to get
the mm sources.
With this PR the error message is avoided and there will be never an
updatenotification when using a tag. This is o.k. because a tag should
never be moved.
Hi,
Like some default modules, I propose to send an `UPDATES` notification
in an array with the git information of these modules
This allows developers to create their own auto-update system (which
I've been using in my case since 3 years, with automatic things)
Of course, for security reasons `MagicMirror` is excluded
---------
Co-authored-by: bugsounet <bugsounet@bugsounet.fr>
- 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.
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>
was [requested in the
forum](https://forum.magicmirror.builders/topic/17519/updatenotification).
- added possibility to exclude MagicMirror Repo and renamed it from
`default` to `MagicMirror`
- improved getting `behind` in case a hard `git fetch` was already done
- removed test "excludes repo if refs don't match regex" because of
above improvement this case is obsolete
- improved `git fetch --dry-run` with `-n` option to exclude tags (noise
reduction)
This PR resolves a small bug in the updatenotification module if a local
git repo is ahead of the remote (for example I have made local commits
for my personal needs).
Currently, if `git status -sb` reports a status like: `##
master...origin/master [ahead 2]` then updatenotification treats this as
though it's "behind".
This PR uses a single Regex to match `git status -sb` output and uses
capture groups to extract info to populate the `gitInfo` object to avoid
needing to do string manipulation to extract this information.
Co-authored-by: Dario Mratovich <dario.mratovich@outlook.com>