jslint -> eslint, formating

Module-Debugging.md

@@ -1,17 +1,19 @@
-### General Debug Tips ###
+## General Debug Tips
 * Remove (or disable) all other modules (except clock) to make it start/run faster and to isolate your module under development.
 * Run your MM in *server mode*, allowing you to still use your RPi (or what have) in GUI mode. CPU resource utilization is also somewhat reduced in server mode. 
 * To prevent unnecessary headaches, utilize automated "linters" when possible before deploying and running your code.
 * Create automated unit and integration tests to protect against unintentional breakages of working features and regression defects.
 
+## Automated Testing vs. Manual Debugging
 
-### Automated Testing vs. Manual Debugging ###
 There is a distinction between the terms "testing" and "debugging". Usually, debugging refers to manually interacting with the application to provoke and analyze its behavior in an attempt to find defects or missing requirements.  Conversely, automated testing involves the creation or utilization of code which validates the syntax and function of your application.
 
-### Automated Testing & Validations ###
+## Automated Testing & Validations
+
 Static code analysis (commonly referred to as "linting") involves a scan and validation of your files against a set of specific set of rules - usually common violations. These scans can be conducted either with a locally installed or a website "linter".
 
-#### Automated config file validation ####
+### Automated config file validation
+
 There is already a local linter installed which can automatically check the MM configuration file. It is invoked with `npm run config:check`, example output below:
 
 ```bash
@@ -29,13 +31,14 @@ Line 35 col 5 Unrecoverable syntax error. (55% scanned).
 user@hostmachine:~/MagicMirror$ 
 ```
 
-#### Automated JS file validation ####
-Utilize a JS linter, such as [jslint.com](http://jslint.com/) and the [jslint on npm](https://www.npmjs.com/package/jslint). 
+### Automated JS file validation
+
+Utilize a JS linter, such as [eslint.org](https://eslint.org/) and the [ESLint on npm](https://www.npmjs.com/package/eslint). 
 
 
 ----
 
-### Manual Debugging ###
+## Manual Debugging ###
 
 This method is tedious, time-consuming, and usually the most frustrating method of troubleshooting. As it can take several seconds and even minutes to restart your MM, it may be a bottleneck for development efficiency. Automated testing and validation are faster, cheaper, and reusable. 
 
@@ -47,7 +50,7 @@ There are at least 2-3 methods to [debugging modules](https://forum.magicmirror.
 
 * It's especially beneficial while debugging at runtime to isolate the module under development by disabling all other modules (except clock). Isolation avoids the startup and performance impact of other modules.
 
-#### Server-mode debugging
+### Server-mode debugging
 
 * Run your MM in *server mode*, allowing you to still use your RPi (or what have) in GUI mode. CPU resource utilization is also somewhat reduced in server mode. 
 * To debug your JS and view `console.log()` output, use your browser's `Developer Tools` (usually activated by `CTRL-SHIFT-i`).
@@ -55,13 +58,14 @@ There are at least 2-3 methods to [debugging modules](https://forum.magicmirror.
 
 ----
 
-### Logging ###
+## Logging
 
-#### Logging Errors and Info to the "console" ####
+### Logging Errors and Info to the "console"
 
 It is usually unclear to first-time users what or where the "console" is. The primary reason for this is that it depends on what, where, and how the log call gets produced. 
 
-##### Logging From *MMM-your-module.js* ####
+#### Logging From *MMM-your-module.js*
+
 Although there are several variations of JS `console.log()` calls, to keep things as simple as possible, MM core provides a few logging wrappers that you can use in your core *MMM-something.js* code. These are:
 
 ```js
@@ -72,7 +76,8 @@ Log.error('error');  # To log to stderr
 
 By default, these log entries will go to the "browser" web console which can be accessed from the DevTools. To start MagicMirror with DevTools open, run `npm start dev` from the MagicMirror folder. If you wish to send these browser logs to the normal console (or PM2 Log Files), add `export ELECTRON_ENABLE_LOGGING=true` to the top of `~/MagicMirror/run-start.sh` and restart.
 
-##### Logging From *node-helper.js*
+#### Logging From *node-helper.js*
+
 These are not available (AFAIK) if you are using a *node_helper.js*, so you'll have to use the standard JS loggers there. As mentioned, there are quite a [few variations](https://console.spec.whatwg.org/#namespacedef-console) of these (and they result in varying success rates) depending on where you want the message to appear. 
 
 * Do you want your log message to go to the Browser (DevTools) log?
@@ -89,20 +94,20 @@ console.dir(any item, optional object? options)
 
 You may also want to take a look at the [MMM-Logging](https://github.com/shbatm/MMM-Logging) 3rd-party module, which will add timestamps and additional formatting to your `console.error()`, or `console.log()` calls.
 
-#### Reviewing logs written to disk ####
+### Reviewing logs written to disk
+
 Check your PM2 logs with `pm2 logs mm` or check the log files in their locations:
   - `/home/pi/.pm2/pm2.log`
   - `/home/pi/.pm2/logs/mm-error-0.log`
   - `/home/pi/.pm2/logs/mm-out-0.log`
 
-
 ---
 
-### Conclusion ###
+## Conclusion
+
 There are probably many other and better ways to check and debug. So please add and edit this page or file an issue with info for improving debugging.
 
-
-### Further Reading ###
+## Further Reading
 
 - [how-to-troubleshoot](https://forum.magicmirror.builders/topic/86/how-to-troubleshoot)
 - [how-to-check-your-config](https://forum.magicmirror.builders/topic/5399/how-to-check-your-config-for-errors-for-absolute-beginners)