loglevel - npm Package Compare versions

Comparing version 1.9.1 to 1.9.2

bower.json

 {
   "name": "loglevel",
-  "version": "1.9.1",
+  "version": "1.9.2",
   "main": "dist/loglevel.min.js",
@@ -5,0 +5,0 @@ "dependencies": {},

CONTRIBUTING.md

@@ -11,10 +11,10 @@ Filing tickets against loglevel
 * Please check the previously opened issues to see if somebody else has suggested it first.
-* Consider submitting a pull request to add the feature instead, if you're confident it fits within the above
+* Consider submitting a pull request to add the feature instead, if you're confident it fits within the above.
 
 If you're filing a bug, please remember:
 
-* To provide detailed steps to reproduce the behaviour
-* If possible, provide a Jasmine test which reproduces the behaviour
-* Please specify the exact details of the environment in which it fails: OS + Environment (i.e. Browser or Node) + version
-* Consider submitting a pull request to fix the bug instead
+* To provide detailed steps to reproduce the behaviour.
+* If possible, provide a Jasmine test which reproduces the behaviour.
+* Please specify the exact details of the environment in which it fails: OS + Environment (i.e. Browser or Node) + version.
+* Consider submitting a pull request to fix the bug instead.
 
@@ -30,22 +30,29 @@ Helping develop loglevel
 
-* You haven't broken the existing test suite in any obvious browsers (at least check latest IE/FF/Chrome)
-* You've added relevant tests for the bug you're fixing/the new feature you're adding/etc, which pass in all the relevant browsers
-* JSHint is happy with your new code
-* You've updated the API docs (in README.md) to detail any changes you've made to the public interface
-* Your change is backward compatible (or you've explicitly said if it's not; this isn't great, but will be considered)
-* You haven't changed any files in dist/ (these are auto-generated, and should only be changed on release)
+* You haven't broken the existing test suite in any obvious browsers (at least check latest IE/FF/Chrome).
+* You've added relevant tests for the bug you're fixing/the new feature you're adding/etc, which pass in all the relevant browsers.
+* JSHint is happy with your new code.
+* You've updated the API docs (in `README.md`) to detail any changes you've made to the public interface.
+* Your change is backward-compatible (or you've explicitly said that it's not; this isn't great, but will be considered).
+* You haven't changed any files in `dist/` (these are auto-generated, and should only be changed on release).
 
+Compatibility and JavaScript Runtimes
+-------------------------------------
+
+loglevel aims to stay compatible with browsers, Node.js versions, and other JS runtimes that may be fairly old at this point! Please take care to match existing conventions and JavaScript language features wherever possible. For example, loglevel uses `var` instead of the newer `let` and `const` keywords to define variables, uses old-style `for` loops instead of the newer `for...of` loop, and so on.
+
+That said, loglevel's *test and development tools* utilize newer JavaScript and Node.js features. To run most tests or build releases, you will need a newer version of Node.js than is required at runtime (see details below in ["how to make your change…"](#how-to-make-your-change-and-submit-it)). Using newer features or making breaking changes to the *dev tools* is OK.
+
 Project structure
 -----------------
 
-The core project code is all in lib/loglevel.js, and this should be the only file you need to touch for functional changes themselves.
+The core project code is all in [`lib/loglevel.js`](./lib/loglevel.js), and this should be the only file you need to touch for functional changes themselves.
 
-The released code is in dist/*.js, and should not be touched by anything except releases
+The released code is in `dist/*.js`, and should not be touched by anything except releases (pull requests should *not* update these files).
 
-The test suite is entirely in test/*.js:
+The test suite is entirely in `test/*.js`:
 
-* Every file ending in '-test.js' is a unit test, is written in RequireJS, and should pass in any environment
-* global-integration.js and node-integration.js are quick integration smoke tests for node and for browser global usage
-* test-helpers.js contains some test utilities
-* manual-test.html is a test page which includes the current loglevel build, so you can manually check it works in a given browser
+* Every file ending in `-test.js` is a unit test, is written in RequireJS, and should pass in any environment.
+* `global-integration.js` and `node-integration.js` are quick integration smoke tests for node and for browser global usage.
+* `test-helpers.js` contains some test utilities.
+* `manual-test.html` is a test page which includes the current loglevel build, so you can manually check that it works in a given browser.
 
@@ -55,11 +62,37 @@ How to make your change and submit it
 
-1. Fork loglevel
-2. Clone your fork locally
-3. Create a branch from master for your change
-4. Write some tests in /test for your change, as relevant
-5. Make your code changes in /lib/loglevel.js
-6. Check your code all passes (run `grunt`) - if you have any issues try running `grunt jasmine:requirejs:src:build` (or a different test build instead of 'requirejs': see the jasmine config in Gruntfile.js) and debugging the generated _SpecRunner.html in a browser
-7. Commit your changes
-8. Open a pull request back to master in loglevel
+1. Ensure you have Node.js v14 or later (some tests can run on earlier versions, but the full suite requires this version).
+2. Fork loglevel.
+3. Clone your fork locally.
+4. Create a branch from `master` for your change.
+5. Write some tests in `test/` for your change, as relevant.
+6. Make your code changes in `lib/loglevel.js`.
+7. Check your code all passes (run `npm test`). If you have issues and need to debug the tests, see the details on ["running tests"](#running-tests) below.
+8. Commit your changes.
+9. Open a pull request back to `master` in loglevel.
 
+Running Tests
+-------------
+
+There are several types of tests and test tools that loglevel uses to verify different types of support in different environments. When you run `npm test`, *all* of these tests are run automatically. However, you may want to run individual types of tests during development, or run some tests manually to debug them.
+
+Test commands (see `"scripts"` in `package.json` for a complete list of tools):
+- `npm test` — Runs all the below tests.
+- `npm run test-browser` — Runs detailed tests in a headless browser. There are actually 3 sub-groups here:
+    - `npx grunt jasmine:global` — Tests general usage of the global `log` variable.
+    - `npx grunt test-browser-context` — Tests usage when loglevel is injected into an anonymous function instead of included as a regular script on the page.
+    - `npx grunt jasmine:requirejs` — Tests the main test suite via Jasmine & RequireJS.
+- `npm run test-node` — Runs tests that check loglevel in Node.js.
+- `npm run test-types` — Runs tests of the TypeScript type definitions for loglevel.
+
+Alternatively, you might want to run tests manually in your browser in order to use debugging tools to step through the code:
+1. Run `npx grunt integration-test` to start a test server on port `8000`.
+2. Your default browser should open the tests automatically, but if not, open `http://127.0.0.1:8000/_SpecRunner.html` in any browser.
+3. Open your browser's dev tools and place breakpoints where you'd like to debug a test.
+4. Reload the page to re-run the tests and pause on breakpoints.
+
+You can also open a blank webpage with loglevel pre-loaded to experiment in your browser's console:
+1. Run `npx grunt integration-test` to start a test server on port `8000`.
+2. In whatever browser you want to test, open `http://127.0.0.1:8000/test/manual-test.html`.
+3. Play around with the global `log` object in the browser's dev console.
+
 Reporting security issues
@@ -66,0 +99,0 @@ -------------------------

dist/loglevel.js

@@ -1,2 +0,2 @@
-/*! loglevel - v1.9.1 - https://github.com/pimterry/loglevel - (c) 2024 Tim Perry - licensed MIT */
+/*! loglevel - v1.9.2 - https://github.com/pimterry/loglevel - (c) 2024 Tim Perry - licensed MIT */
 (function (root, definition) {
@@ -3,0 +3,0 @@ "use strict";

dist/loglevel.min.js

@@ -1,3 +0,3 @@
-/*! loglevel - v1.9.1 - https://github.com/pimterry/loglevel - (c) 2024 Tim Perry - licensed MIT */
+/*! loglevel - v1.9.2 - https://github.com/pimterry/loglevel - (c) 2024 Tim Perry - licensed MIT */
 
 !function(e,o){"use strict";"function"==typeof define&&define.amd?define(o):"object"==typeof module&&module.exports?module.exports=o():e.log=o()}(this,function(){"use strict";var l=function(){},f="undefined",i=typeof window!==f&&typeof window.navigator!==f&&/Trident\/|MSIE /.test(window.navigator.userAgent),s=["trace","debug","info","warn","error"],p={},d=null;function r(o,e){var n=o[e];if("function"==typeof n.bind)return n.bind(o);try{return Function.prototype.bind.call(n,o)}catch(e){return function(){return Function.prototype.apply.apply(n,[o,arguments])}}}function c(){console.log&&(console.log.apply?console.log.apply(console,arguments):Function.prototype.apply.apply(console.log,[console,arguments])),console.trace&&console.trace()}function v(){for(var e=this.getLevel(),o=0;o<s.length;o++){var n=s[o];this[n]=o<e?l:this.methodFactory(n,e,this.name)}if(this.log=this.debug,typeof console===f&&e<this.levels.SILENT)return"No console available for logging"}function y(e,o,n){return"debug"===(t=e)&&(t="log"),typeof console!==f&&("trace"===t&&i?c:void 0!==console[t]?r(console,t):void 0!==console.log?r(console,"log"):l)||function(e){return function(){typeof console!==f&&(v.call(this),this[e].apply(this,arguments))}}.apply(this,arguments);var t}function n(e,o){var n,t,l,i=this,r="loglevel";function c(){var e;if(typeof window!==f&&r){try{e=window.localStorage[r]}catch(e){}if(typeof e===f)try{var o=window.document.cookie,n=encodeURIComponent(r),t=o.indexOf(n+"=");-1!==t&&(e=/^([^;]+)/.exec(o.slice(t+n.length+1))[1])}catch(e){}return void 0===i.levels[e]&&(e=void 0),e}}function a(e){var o=e;if("string"==typeof o&&void 0!==i.levels[o.toUpperCase()]&&(o=i.levels[o.toUpperCase()]),"number"==typeof o&&0<=o&&o<=i.levels.SILENT)return o;throw new TypeError("log.setLevel() called with invalid level: "+e)}"string"==typeof e?r+=":"+e:"symbol"==typeof e&&(r=void 0),i.name=e,i.levels={TRACE:0,DEBUG:1,INFO:2,WARN:3,ERROR:4,SILENT:5},i.methodFactory=o||y,i.getLevel=function(){return null!=l?l:null!=t?t:n},i.setLevel=function(e,o){return l=a(e),!1!==o&&function(e){var o=(s[e]||"silent").toUpperCase();if(typeof window!==f&&r){try{return window.localStorage[r]=o}catch(e){}try{window.document.cookie=encodeURIComponent(r)+"="+o+";"}catch(e){}}}(l),v.call(i)},i.setDefaultLevel=function(e){t=a(e),c()||i.setLevel(e,!1)},i.resetLevel=function(){l=null,function(){if(typeof window!==f&&r){try{window.localStorage.removeItem(r)}catch(e){}try{window.document.cookie=encodeURIComponent(r)+"=; expires=Thu, 01 Jan 1970 00:00:00 UTC"}catch(e){}}}(),v.call(i)},i.enableAll=function(e){i.setLevel(i.levels.TRACE,e)},i.disableAll=function(e){i.setLevel(i.levels.SILENT,e)},i.rebuild=function(){if(d!==i&&(n=a(d.getLevel())),v.call(i),d===i)for(var e in p)p[e].rebuild()},n=a(d?d.getLevel():"WARN");var u=c();null!=u&&(l=a(u)),v.call(i)}(d=new n).getLogger=function(e){if("symbol"!=typeof e&&"string"!=typeof e||""===e)throw new TypeError("You must supply a name when creating a logger.");var o=p[e];return o||(o=p[e]=new n(e,d.methodFactory)),o};var e=typeof window!==f?window.log:void 0;return d.noConflict=function(){return typeof window!==f&&window.log===d&&(window.log=e),d},d.getLoggers=function(){return p},d.default=d});

Gruntfile.js

@@ -156,3 +156,4 @@ 'use strict';
     grunt.registerTask('test', ['jshint', 'test-browser', 'test-node']);
-    grunt.registerTask('test-browser', ['jasmine:global', 'preprocess', 'jasmine:context', 'clean:test', 'jasmine:requirejs']);
+    grunt.registerTask('test-browser', ['jasmine:global', 'test-browser-context', 'jasmine:requirejs']);
+    grunt.registerTask('test-browser-context', ['preprocess', 'jasmine:context', 'clean:test']);
     grunt.registerTask('test-node', ['jasmine_node']);
@@ -159,0 +160,0 @@

package.json

 {
   "name": "loglevel",
   "description": "Minimal lightweight logging for JavaScript, adding reliable log level methods to any available console.log methods",
-  "version": "1.9.1",
+  "version": "1.9.2",
   "homepage": "https://github.com/pimterry/loglevel",
@@ -33,3 +33,3 @@ "author": {
     "test-node": "grunt test-node",
-    "test-types": "tsc --noEmit ./test/type-test.ts",
+    "test-types": "tsc --noEmit ./test/type-test.ts && ts-node ./test/type-test.ts",
     "dist": "grunt dist",
@@ -43,9 +43,9 @@ "dist-build": "grunt dist-build",
     "@types/node": "^12.0.4",
-    "grunt": "~1.0.4",
-    "grunt-cli": "~1.2.0",
+    "grunt": "~1.5.3",
+    "grunt-cli": "^1.4.3",
     "grunt-contrib-clean": "^1.1.0",
     "grunt-contrib-concat": "~0.5.0",
-    "grunt-contrib-connect": "^1.0.2",
+    "grunt-contrib-connect": "^3.0.0",
     "grunt-contrib-jasmine": "^4.0.0",
-    "grunt-contrib-jshint": "^1.1.0",
+    "grunt-contrib-jshint": "^3.2.0",
     "grunt-contrib-uglify": "^3.4.0",
@@ -56,2 +56,3 @@ "grunt-contrib-watch": "^1.1.0",
     "jasmine": "^2.4.1",
+    "ts-node": "^10.9.2",
     "typescript": "^3.5.1"
@@ -58,0 +59,0 @@ },

README.md

@@ -9,3 +9,3 @@
 
-Minimal lightweight simple logging for JavaScript (browsers, node.js or elsewhere). loglevel extends console.log() & friends with level-based logging and filtering, with none of console's downsides.
+Minimal lightweight simple logging for JavaScript (browsers, node.js or elsewhere). loglevel extends `console.log()` & friends with level-based logging and filtering, with none of console's downsides.
 
@@ -20,20 +20,20 @@ Test it out live in your browser console at https://pimterry.github.io/loglevel/demo/index.html
 
-* Log things at a given level (trace/debug/info/warn/error) to the console object (as seen in all modern browsers & node.js)
-* Filter logging by level (all the above or 'silent'), so you can disable all but error logging in production, and then run log.setLevel("trace") in your console to turn it all back on for a furious debugging session
-* Single file, no dependencies, weighs in at 1.1KB minified and gzipped
+* Log things at a given level (trace/debug/info/warn/error) to the `console` object (as seen in all modern browsers & node.js).
+* Filter logging by level (all the above or 'silent'), so you can disable all but error logging in production, and then run `log.setLevel("trace")` in your console to turn it all back on for a furious debugging session.
+* Single file, no dependencies, weighs in at 1.4 KB minified and gzipped.
 
 ### Effective
 
-* Log methods gracefully fall back to simpler console logging methods if more specific ones aren't available: so calls to log.debug() go to console.debug() if possible, or console.log() if not
-* Logging calls still succeed even if there's no console object at all, so your site doesn't break when people visit with old browsers that don't support the console object (here's looking at you IE) and similar
-* This then comes together giving a consistent reliable API that works in every JavaScript environment with a console available, and never breaks anything anywhere else
+* Log methods gracefully fall back to simpler console logging methods if more specific ones aren't available: so calls to `log.debug()` go to `console.debug()` if possible, or `console.log()` if not.
+* Logging calls still succeed even if there's no `console` object at all, so your site doesn't break when people visit with old browsers that don't support the `console` object (here's looking at you, IE) and similar.
+* This then comes together giving a consistent reliable API that works in every JavaScript environment with a console available, and never breaks anything anywhere else.
 
 ### Convenient
 
-* Log output keeps line numbers: most JS logging frameworks call console.log methods through wrapper functions, clobbering your stacktrace and making the extra info many browsers provide useless. We'll have none of that thanks.
-* It works with all the standard JavaScript loading systems out of the box (CommonJS, AMD, or just as a global)
-* Logging is filtered to "warn" level by default, to keep your live site clean in normal usage (or you can trivially re-enable everything with an initial log.enableAll() call)
-* Magically handles situations where console logging is not initially available (IE8/9), and automatically enables logging as soon as it does become available (when developer console is opened)
-* TypeScript type definitions included, so no need for extra `@types` packages
-* Extensible, to add other log redirection, filtering, or formatting functionality, while keeping all the above (except you will clobber your stacktrace, see Plugins below)
+* Log output keeps line numbers: most JS logging frameworks call `console.log` methods through wrapper functions, clobbering your stacktrace and making the extra info many browsers provide useless. We'll have none of that thanks.
+* It works with all the standard JavaScript loading systems out of the box (CommonJS, AMD, or just as a global).
+* Logging is filtered to "warn" level by default, to keep your live site clean in normal usage (or you can trivially re-enable everything with an initial `log.enableAll()` call).
+* Magically handles situations where console logging is not initially available (IE8/9), and automatically enables logging as soon as it does become available (when developer console is opened).
+* TypeScript type definitions included, so no need for extra `@types` packages.
+* Extensible, to add other log redirection, filtering, or formatting functionality, while keeping all the above (except you will clobber your stacktrace, see [“Plugins”](#plugins) below).
 
@@ -56,3 +56,3 @@ ## Downloading loglevel
 
-loglevel supports AMD (e.g. RequireJS), CommonJS (e.g. Node.js) and direct usage (e.g. loading globally with a <script> tag) loading methods. You should be able to do nearly anything, and then skip to the next section anyway and have it work. Just in case though, here's some specific examples that definitely do the right thing:
+loglevel supports AMD (e.g. RequireJS), CommonJS (e.g. Node.js) and direct usage (e.g. loading globally with a `<script>` tag) loading methods. You should be able to do nearly anything, and then skip to the next section anyway and have it work. Just in case, though, here's some specific examples that definitely do the right thing:
 
@@ -85,3 +85,3 @@ ### CommonsJS (e.g. Node)
 
-loglevel is written as a UMD module, with a single object exported. Unfortunately ES6 module loaders & transpilers don't all handle this the same way. Some will treat the object as the default export, while others use it as the root exported object. In addition, loglevel includes `default` property on the root object, designed to help handle this differences. Nonetheless, there's two possible syntaxes that might work for you:
+loglevel is written as a UMD module, with a single object exported. Unfortunately, ES6 module loaders & transpilers don't all handle this the same way. Some will treat the object as the default export, while others use it as the root exported object. In addition, loglevel includes a `default` property on the root object, designed to help handle this difference. Nonetheless, there are two possible syntaxes that might work for you:
 
@@ -106,3 +106,3 @@ For most tools, using the default import is the most convenient and flexible option:
 
-If you're using another JavaScript library that exposes a 'log' global, you can run into conflicts with loglevel.  Similarly to jQuery, you can solve this by putting loglevel into no-conflict mode immediately after it is loaded onto the page. This resets to 'log' global to its value before loglevel was loaded (typically `undefined`), and returns the loglevel object, which you can then bind to another name yourself.
+If you're using another JavaScript library that exposes a `log` global, you can run into conflicts with loglevel. Similarly to jQuery, you can solve this by putting loglevel into no-conflict mode immediately after it is loaded onto the page. This resets the `log` global to its value before loglevel was loaded (typically `undefined`), and returns the loglevel object, which you can then bind to another name yourself.
 
@@ -140,3 +140,3 @@ For example:
 
-The loglevel API is extremely minimal. All methods are available on the root loglevel object, which it's suggested you name 'log' (this is the default if you import it in globally, and is what's set up in the above examples). The API consists of:
+The loglevel API is extremely minimal. All methods are available on the root loglevel object, which we suggest you name `log` (this is the default if you import it globally, and is what's set up in the above examples). The API consists of:
 
@@ -155,7 +155,7 @@ #### Logging Methods
 
-Exact output formatting of these will depend on the console available in the current context of your application. For example, many environments will include a full stack trace with all trace() calls, and icons or similar to highlight other calls.
+Exact output formatting of these will depend on the console available in the current context of your application. For example, many environments will include a full stack trace with all `trace()` calls, and icons or similar to highlight other calls.
 
-These methods should never fail in any environment, even if no console object is currently available, and should always fall back to an available log method even if the specific method called (e.g. warn) isn't available.
+These methods should never fail in any environment, even if no `console` object is currently available, and should always fall back to an available log method even if the specific method called (e.g. `warn`) isn't available.
 
-Be aware that all this means that these method won't necessarily always produce exactly the output you expect in every environment; loglevel only guarantees that these methods will never explode on you, and that it will call the most relevant method it can find, with your argument. For example, `log.trace(msg)` in Firefox before version 64 prints the stacktrace by itself, and doesn't include your message (see [#84](https://github.com/pimterry/loglevel/issues/84)).
+Be aware that this means that these methods won't always produce exactly the output you expect in every environment; loglevel only guarantees that these methods will never explode on you, and that it will call the most relevant method it can find, with your argument. For example, `log.trace(msg)` in Firefox before version 64 prints the stacktrace by itself, and doesn't include your message (see [#84](https://github.com/pimterry/loglevel/issues/84)).
 
@@ -172,11 +172,11 @@ #### `log.setLevel(level, [persist])`
 
-Where possible, the log level will be persisted. LocalStorage will be used if available, falling back to cookies if not. If neither is available in the current environment (i.e. in Node), or if you pass `false` as the optional 'persist' second argument, persistence will be skipped.
+Where possible, the log level will be persisted. LocalStorage will be used if available, falling back to cookies if not. If neither is available in the current environment (e.g. in Node), or if you pass `false` as the optional 'persist' second argument, persistence will be skipped.
 
-If `log.setLevel()` is called when a console object is not available (in IE 8 or 9 before the developer tools have been opened, for example) logging will remain silent until the console becomes available, and then begin logging at the requested level.
+If `log.setLevel()` is called when a `console` object is not available (in IE 8 or 9 before the developer tools have been opened, for example) logging will remain silent until the console becomes available, and then begin logging at the requested level.
 
 #### `log.setDefaultLevel(level)`
 
-This sets the current log level only if one has not been persisted and can’t be loaded. This is useful when initializing modules or scripts; if a developer or user has previously called `setLevel()`, this won’t alter their settings. For example, your application might set the log level to `error` in a production environment, but when debugging an issue, you might call `setLevel("trace")` on the console to see all the logs. If that `error` setting was set using `setDefaultLevel()`, it will still stay as `trace` on subsequent page loads and refreshes instead of resetting to `error`.
+This sets the current log level only if one has not been persisted and can’t be loaded. This is useful when initializing modules or scripts; if a developer or user has previously called `setLevel()`, this won’t alter their settings. For example, your application might use `setDefaultLevel("error")` set the log level to `error` in a production environment, but when debugging an issue, you might call `setLevel("trace")` on the console to see all the logs. If that `error` setting was set using `setDefaultLevel()`, it will still stay as `trace` on subsequent page loads and refreshes instead of resetting to `error`.
 
-The `level` argument takes is the same values that you might pass to `setLevel()`. Levels set using `setDefaultLevel()` never persist to subsequent page loads.
+The `level` argument takes the same values that you might pass to `setLevel()`. Levels set using `setDefaultLevel()` never persist to subsequent page loads.
 
@@ -189,7 +189,7 @@ #### `log.resetLevel()`
 
-These enable or disable all log messages, and are equivalent to log.setLevel("trace") and log.setLevel("silent") respectively.
+These enable or disable all log messages, and are equivalent to `log.setLevel("trace")` and `log.setLevel("silent")`, respectively.
 
 #### `log.getLevel()`
 
-Returns the current logging level, as a number from 0 (trace) to 5 (silent)
+Returns the current logging level, as a number from `0` (trace) to `5` (silent)
 
@@ -205,7 +205,7 @@ It's very unlikely you'll need to use this for normal application logging; it's provided partly to help plugin development, and partly to let you optimize logging code as below, where debug data is only generated if the level is set such that it'll actually be logged. This probably doesn't affect you, unless you've run profiling on your code and you have hard numbers telling you that your log data generation is a real performance problem.
 
-This notably isn't the right solution to avoid the cost of string concatenation in your logging. Firstly, it's very unlikely that string concatenation in your logging is really an important performance problem. Even if you do genuinely have hard metrics showing that it is though, the better solution that wrapping your log statements in this is to use multiple arguments, as below. The underlying console API will automatically concatenate these for you if logging is enabled, and if it isn't then all log methods are no-ops, and no concatenation will be done at all.
+This notably isn't the right solution to avoid the cost of string concatenation in your logging. Firstly, it's very unlikely that string concatenation in your logging is really an important performance problem. Even if you do genuinely have hard metrics showing that it is, though, the better solution that wrapping your log statements in this is to use multiple arguments, as below. The underlying console API will automatically concatenate these for you if logging is enabled, and if it isn't then all log methods are no-ops, and no concatenation will be done at all.
 
 ```javascript
 // Prints 'My concatenated log message'
-log.debug("My ", "concatenated ", "log message");
+log.debug("My", "concatenated", "log message");
 ```
@@ -250,9 +250,9 @@
 
-Like the root logger, other loggers can have their logging level saved. If a logger’s level has not been saved, it will inherit the root logger’s level when it is first created. If the root logger’s level changes later, the new level will not affect other loggers that have already been created. Loggers with Symbol names (rather than string names) will be always considered as unique instances, and will never have their logging level saved or restored.
+Like the root logger, other loggers can have their logging level saved. If a logger’s level has not been saved, it will inherit the root logger’s level when it is first created. If the root logger’s level changes later, the new level will not affect other loggers that have already been created. Loggers with Symbol names (rather than string names) will always be considered unique instances, and will never have their logging level saved or restored.
 
-Likewise, loggers will inherit the root logger’s `methodFactory`. After creation, each logger can have its `methodFactory` independently set. See the _plugins_ section below for more about `methodFactory`.
+Likewise, loggers inherit the root logger’s `methodFactory`. After creation, each logger can have its `methodFactory` independently set. See the _plugins_ section below for more about `methodFactory`.
 
 #### `log.getLoggers()`
 
-This will return you the dictionary of all loggers created with `getLogger`, keyed off of their names.
+This will return the dictionary of all loggers created with `getLogger()`, keyed by their names.
 
@@ -295,13 +295,13 @@ #### `log.rebuild()`
 
-ServerSend - <https://github.com/artemyarulin/loglevel-serverSend> - Forward your log messages to a remote server.
+[loglevel-serverSend](https://github.com/artemyarulin/loglevel-serverSend) - Forward your log messages to a remote server.
 
-DEBUG - <https://github.com/vectrlabs/loglevel-debug> - Control logging from a DEBUG environmental variable (similar to the classic [Debug](https://github.com/visionmedia/debug) module)
+[loglevel-debug](https://github.com/vectrlabs/loglevel-debug) - Control logging from a DEBUG environmental variable (similar to the classic [Debug](https://github.com/visionmedia/debug) module).
 
 ### Writing plugins
 
-Loglevel provides a simple reliable minimal base for console logging that works everywhere. This means it doesn't include lots of fancy functionality that might be useful in some cases, such as log formatting and redirection (e.g. also sending log messages to a server over AJAX)
+Loglevel provides a simple, reliable, minimal base for console logging that works everywhere. This means it doesn't include lots of fancy functionality that might be useful in some cases, such as log formatting and redirection (e.g. also sending log messages to a server over AJAX)
 
-Including that would increase the size and complexity of the library, but more importantly would remove stacktrace information. Currently log methods are either disabled, or enabled with directly bound versions of the console.log methods (where possible). This means your browser shows the log message as coming from your code at the call to `log.info("message!")` not from within loglevel, since it really calls the bound console method directly, without indirection. The indirection required to dynamically format, further filter, or redirect log messages would stop this.
+Including that would increase the size and complexity of the library, but more importantly would remove stacktrace information. Currently log methods are either disabled, or enabled with directly bound versions of the `console.log` methods (where possible). This means your browser shows the log message as coming from your code at the call to `log.info("message!")` not from within loglevel, since it really calls the bound console method directly, without indirection. The indirection required to dynamically format, further filter, or redirect log messages would stop this.
 
-There's clearly enough enthusiasm for this even at that cost though that loglevel now includes a plugin API. To use it, redefine `log.methodFactory(methodName, logLevel, loggerName)` with a function of your own. This will be called for each enabled method each time the level is set (including initially), and should return a function to be used for the given log method `methodName`, at the given _configured_ (not actual) level `logLevel`, for a logger with the given name `loggerName`. If you'd like to retain all the reliability and features of loglevel, it's recommended that this wraps the initially provided value of `log.methodFactory`.
+There's clearly enough enthusiasm for this even at that cost that loglevel now includes a plugin API. To use it, redefine `log.methodFactory(methodName, logLevel, loggerName)` with a function of your own. This will be called for each enabled method each time the level is set (including initially), and should return a function to be used for the given log method `methodName`, at the given _configured_ (not actual) level `logLevel`, for a logger with the given name `loggerName`. If you'd like to retain all the reliability and features of loglevel, we recommended that you wrap the initially provided value of `log.methodFactory`.
 
@@ -324,3 +324,3 @@ For example, a plugin to prefix all log messages with "Newsflash: " would look like:
 
-If you develop and release a plugin, please get in contact! I'd be happy to reference it here for future users. Some consistency is helpful; naming your plugin 'loglevel-PLUGINNAME' (e.g. loglevel-newsflash) is preferred, as is giving it the 'loglevel-plugin' keyword in your package.json
+If you develop and release a plugin, please get in contact! I'd be happy to reference it here for future users. Some consistency is helpful; naming your plugin 'loglevel-PLUGINNAME' (e.g. loglevel-newsflash) is preferred, as is giving it the 'loglevel-plugin' keyword in your `package.json`.
 
@@ -331,5 +331,5 @@ ## Developing & Contributing
 
-Builds can be run with npm: run `npm run dist` to build a distributable version of the project (in /dist), or `npm test` to just run the tests and linting. During development you can run `npm run watch` and it will monitor source files, and rerun the tests and linting as appropriate when they're changed.
+Builds can be run with npm: run `npm run dist` to build a distributable version of the project (in `dist/`), or `npm test` to just run the tests and linting. During development you can run `npm run watch` and it will monitor source files, and rerun the tests and linting as appropriate when they're changed.
 
-_Also, please don't manually edit files in the "dist" subdirectory as they are generated via Grunt. You'll find source code in the "lib" subdirectory!_
+_Also, please don't manually edit files in the `dist/` subdirectory as they are generated via Grunt. You'll find source code in the `lib/` subdirectory!_
 
@@ -340,8 +340,8 @@ #### Release process
 
-* Update the version number in package.json and bower.json
-* Run `npm run dist` to build a distributable version in dist/
-* Update the release history in this file (below)
-* Commit the built code, tagging it with the version number and a brief message about the release
-* Push to Github
-* Run `npm publish .` to publish to NPM
+* Update the version number in `package.json` and `bower.json`.
+* Run `npm run dist` to build a distributable version in `dist/`.
+* Update the release history in this file (below).
+* Commit the built code, tagging it with the version number and a brief message about the release.
+* Push to Github.
+* Run `npm publish .` to publish to NPM.
 
@@ -354,3 +354,3 @@ ## Release History
 
-v0.3.0 - Some bugfixes (#12, #14), cookie-based log level persistence, doc tweaks, support for Bower and JamJS
+v0.3.0 - Some bugfixes ([#12](https://github.com/pimterry/loglevel/issues/12), [#14](https://github.com/pimterry/loglevel/issues/14)), cookie-based log level persistence, doc tweaks, support for Bower and JamJS
 
@@ -363,23 +363,23 @@ v0.3.1 - Fixed incorrect text in release build banner, various other minor tweaks
 
-v0.6.0 - Handle logging in Safari private browsing mode (#33), fix TRACE level persistence bug (#35), plus various minor tweaks
+v0.6.0 - Handle logging in Safari private browsing mode ([#33](https://github.com/pimterry/loglevel/issues/33)), fix `TRACE` level persistence bug ([#35](https://github.com/pimterry/loglevel/issues/35)), plus various minor tweaks
 
-v1.0.0 - Official stable release! Fixed a bug with localStorage in Android webviews, improved CommonJS detection, and added noConflict().
+v1.0.0 - Official stable release! Fixed a bug with localStorage in Android webviews, improved CommonJS detection, and added `noConflict()`.
 
-v1.1.0 - Added support for including loglevel with preprocessing and .apply() (#50), and fixed QUnit dep version which made tests potentially unstable.
+v1.1.0 - Added support for including loglevel with preprocessing and `.apply()` ([#50](https://github.com/pimterry/loglevel/issues/50)), and fixed QUnit dep version which made tests potentially unstable.
 
 v1.2.0 - New plugin API! Plus various bits of refactoring and tidy up, nicely simplifying things and trimming the size down.
 
-v1.3.0 - Make persistence optional in setLevel, plus lots of documentation updates and other small tweaks
+v1.3.0 - Make persistence optional in `setLevel()`, plus lots of documentation updates and other small tweaks
 
-v1.3.1 - With the new optional persistence, stop unnecessarily persisting the initially set default level (warn)
+v1.3.1 - With the new optional persistence, stop unnecessarily persisting the initially set default level (`WARN`)
 
-v1.4.0 - Add getLevel(), setDefaultLevel() and getLogger() functionality for more fine-grained log level control
+v1.4.0 - Add `getLevel()`, `setDefaultLevel()` and `getLogger()` functionality for more fine-grained log level control
 
-v1.4.1 - Reorder UMD (#92) to improve bundling tool compatibility
+v1.4.1 - Reorder UMD ([#92](https://github.com/pimterry/loglevel/issues/92)) to improve bundling tool compatibility
 
-v1.5.0 - Fix log.debug (#111) after V8 changes deprecating console.debug, check for `window` upfront (#104), and add `.log` alias for `.debug` (#64)
+v1.5.0 - Fix `log.debug` ([#111](https://github.com/pimterry/loglevel/issues/111)) after V8 changes deprecating console.debug, check for `window` upfront ([#104](https://github.com/pimterry/loglevel/issues/104)), and add `.log` alias for `.debug` ([#64](https://github.com/pimterry/loglevel/issues/64))
 
-v1.5.1 - Fix bug (#112) in level-persistence cookie fallback, which failed if it wasn't the first cookie present
+v1.5.1 - Fix bug ([#112](https://github.com/pimterry/loglevel/issues/112)) in level-persistence cookie fallback, which failed if it wasn't the first cookie present
 
-v1.6.0 - Add a name property to loggers and add log.getLoggers() (#114), and recommend unpkg as CDN instead of CDNJS.
+v1.6.0 - Add a name property to loggers and add `log.getLoggers()` ([#114](https://github.com/pimterry/loglevel/issues/114)), and recommend unpkg as CDN instead of CDNJS.
 
@@ -392,5 +392,5 @@ v1.6.1 - Various small documentation & test updates
 
-v1.6.4 - Ensure package.json's 'main' is a fully qualified path, to fix webpack issues
+v1.6.4 - Ensure `package.json`'s `"main"` is a fully qualified path, to fix webpack issues
 
-v1.6.5 - Ensure the provided message is included when calling trace() in IE11
+v1.6.5 - Ensure the provided message is included when calling `trace()` in IE11
 
@@ -409,3 +409,3 @@ v1.6.6 - Fix bugs in v1.6.5, which caused issues in node.js & IE < 9
 
-v1.8.1 - Fix incorrect type definitions for MethodFactory
+v1.8.1 - Fix incorrect type definitions for `MethodFactory`
 
@@ -416,2 +416,4 @@ v1.9.0 - Added `rebuild()` method, overhaul dev & test setup, and fix some bugs (notably around cookies) en route
 
+v1.9.2 - Remove unnecessarily extra test & CI files from deployed package
+
 ## `loglevel` for enterprise
@@ -426,2 +428,2 @@
 Copyright (c) 2013 Tim Perry
-Licensed under the MIT license.
+Licensed under the MIT license. See [`LICENSE-MIT`](./LICENSE-MIT) for full license text.

New alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Major refactor

Supply chain risk

Package has recently undergone a major refactor. It may be unstable or indicate significant internal changes. Use caution when updating to versions that include significant changes.

Found 1 instance in 1 package

Fixed alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Network access

Supply chain risk

This module accesses the network.

Found 1 instance in 1 package

Uses eval

Supply chain risk

Package uses dynamic code execution (e.g., eval()), which is a dangerous practice. This can prevent the code from running in certain environments and increases the risk that the code may contain exploits or malicious behavior.

Found 1 instance in 1 package

Dynamic require

Supply chain risk

Dynamic require can indicate the package is performing dangerous or unsafe dynamic code execution.

Found 1 instance in 1 package

Environment variable access

Supply chain risk

Package accesses environment variables, which may be a sign of credential stuffing or data theft.

Found 1 instance in 1 package

Minified code

Quality

This package contains minified code. This may be harmless in some cases where minified code is included in packaged libraries, however packages on npm should not minify code.

Found 1 instance in 1 package

Improved metrics

Number of low quality alerts

0

decreased by-100%

Number of lines in readme file

409

increased by0.49%

Number of low supply chain risk alerts

0

decreased by-100%

Number of medium supply chain risk alerts

1

decreased by-95.45%

Worsened metrics

Total package byte prevSize

86169

decreased by-86.51%

Dev dependency count

16

increased by6.67%

Number of package files

15

decreased by-75.81%

Lines of code

1105

decreased by-88.14%

No dependency changes