feat: Add unit tests for disable return value
fix: Correct spelling in test case description
feat: Test that disable-string works with enable again
Closes#523
docs: Add section about disable return value
* Adding TVMLKit support
* removed the check for window/navigationDocument, instead relying on localStorage in the global context on all 'browser' based platforms
Squashed commit of the following:
commit 62589c0a4e1babc5953ea30c7ef80b3867ed0a04
Author: Adrian Mejia <admejiar@cisco.com>
Date: Sat Aug 12 15:24:45 2017 -0400
solves merge conflict
commit 55e5c5e86812163293779e9bbad1afc252c83230
Author: Adrian Mejia <admejiar@cisco.com>
Date: Sat Aug 12 15:21:16 2017 -0400
docs
commit e09dec33c15fae136039c7ebd94c23000a35373f
Author: Adrian Mejia <admejiar@cisco.com>
Date: Sat Aug 12 15:19:10 2017 -0400
cleanup
commit 9dd6a2b9ca3b1f0d9852ecf0e64ccc6dacf04fa7
Author: Adrian Mejia <admejiar@cisco.com>
Date: Sat Aug 12 15:05:53 2017 -0400
enables DEBUG_HIDE_TTY_DATE
* dynamically updatable instances
* add a `destroy()` function to debug instances
So that "dynamically created instances" can clean up after themselves
* Make millisecond timer namespace specific
When debugging node apps, I find it much more useful for the
millisecond timer to be relative to last message from the same
namespace instead of any message. This is especially true when I'm
debugging across multiple libraries or multiple levels in the same
module and I'm interested in seeing all the messages but also need to
compare times from specific levels.
* Enable 'always enabled' output
Having to deal with 2 different logging mechanisms, one for debugging
and one for normal output, can be a nuisance. It would be much easier to
always use the same facility and semantics for both. This patch allows
an 'always enabled' namespace to be specified by appending a single '*'
to the namespace name.
var alwaysOn = require('debug')('normal:messages*');
alwaysOn('This will always display regardless of DEBUG');
* remove DEBUG_FD
Now simply uses `process.stderr`. Breaking API change,
for the v3 branch.
Previously used internal and undocumented Node.js APIs to support
this underly used API.
Fixes#280Closes#386
* remove DEBUG_FD from readme
The browser version assumes that chrome.storage.local uses an API which is compatible with localStorage; which is not the case. Even though I am using chrome.storage.local for my Chrome extension, I would much prefer to keep debug's variable in localStorage, as I consider chrome.storage.local the 'private space' of my extension.
This change obviates the need to support multiple storage types. But if storage type is important, how about supporting a custom storage facility, including chrome.storage.sync? I.e. the user would provide an object that follows the conventions. Just a thought - I certainly don't see the need at this point though.
* Check for undefined on browser globals.
Not all environments include these globals. For example, web workers do not have global window objects.
* remove redundant global checks
* Hide in DEBUG_FD deprecation warning in Webstorm Fixes#410
+ Intellij idea
* Hide in DEBUG_FD deprecation warning in Webstorm Fixes#410
* whitelist DEBUG_FD for values 1 and 2 only
* Use appreciate depreciation message
