@veecode-platform/backstage-plugin-about-backend-dynamic 1.0.1 → 1.0.2

package/node_modules/safe-stable-stringify/readme.md

@@ -1,179 +0,0 @@
-# safe-stable-stringify
-
-Safe, deterministic and fast serialization alternative to [JSON.stringify][].
-Zero dependencies. ESM and CJS. 100% coverage.
-
-Gracefully handles circular structures and bigint instead of throwing.
-
-Optional custom circular values, deterministic behavior or strict JSON
-compatibility check.
-
-## stringify(value[, replacer[, space]])
-
-The same as [JSON.stringify][].
-
-* `value` {any}
-* `replacer` {string[]|function|null}
-* `space` {number|string}
-* Returns: {string}
-
-```js
-const stringify = require('safe-stable-stringify')
-
-const bigint = { a: 0, c: 2n, b: 1 }
-
-stringify(bigint)
-// '{"a":0,"b":1,"c":2}'
-JSON.stringify(bigint)
-// TypeError: Do not know how to serialize a BigInt
-
-const circular = { b: 1, a: 0 }
-circular.circular = circular
-
-stringify(circular)
-// '{"a":0,"b":1,"circular":"[Circular]"}'
-JSON.stringify(circular)
-// TypeError: Converting circular structure to JSON
-
-stringify(circular, ['a', 'b'], 2)
-// {
-//   "a": 0,
-//   "b": 1
-// }
-```
-
-## stringify.configure(options)
-
-* `bigint` {boolean} If `true`, bigint values are converted to a number. Otherwise
-  they are ignored. **Default:** `true`.
-* `circularValue` {string|null|undefined|ErrorConstructor} Defines the value for
-  circular references. Set to `undefined`, circular properties are not
-  serialized (array entries are replaced with `null`). Set to `Error`, to throw
-  on circular references. **Default:** `'[Circular]'`.
-* `deterministic` {boolean|function} If `true` or a `Array#sort(comparator)`
-  comparator method, guarantee a deterministic key order instead of relying on
-  the insertion order. **Default:** `true`.
-* `maximumBreadth` {number} Maximum number of entries to serialize per object
-  (at least one). The serialized output contains information about how many
-  entries have not been serialized. Ignored properties are counted as well
-  (e.g., properties with symbol values). Using the array replacer overrules this
-  option. **Default:** `Infinity`
-* `maximumDepth` {number} Maximum number of object nesting levels (at least 1)
-  that will be serialized. Objects at the maximum level are serialized as
-  `'[Object]'` and arrays as `'[Array]'`. **Default:** `Infinity`
-* `strict` {boolean} Instead of handling any JSON value gracefully, throw an
-  error in case it may not be represented as JSON (functions, NaN, ...).
-  Circular values and bigint values throw as well in case either option is not
-  explicitly defined. Sets and Maps are not detected as well as Symbol keys!
-  **Default:** `false`
-* Returns: {function} A stringify function with the options applied.
-
-```js
-import { configure } from 'safe-stable-stringify'
-
-const stringify = configure({
-  bigint: true,
-  circularValue: 'Magic circle!',
-  deterministic: false,
-  maximumDepth: 1,
-  maximumBreadth: 4
-})
-
-const circular = {
-  bigint: 999_999_999_999_999_999n,
-  typed: new Uint8Array(3),
-  deterministic: "I don't think so",
-}
-circular.circular = circular
-circular.ignored = true
-circular.alsoIgnored = 'Yes!'
-
-const stringified = stringify(circular, null, 4)
-
-console.log(stringified)
-// {
-//     "bigint": 999999999999999999,
-//     "typed": "[Object]",
-//     "deterministic": "I don't think so",
-//     "circular": "Magic circle!",
-//     "...": "2 items not stringified"
-// }
-
-const throwOnCircular = configure({
-  circularValue: Error
-})
-
-throwOnCircular(circular);
-// TypeError: Converting circular structure to JSON
-```
-
-## Differences to JSON.stringify
-
-1. _Circular values_ are replaced with the string `[Circular]` (configurable).
-1. _Object keys_ are sorted instead of using the insertion order (configurable).
-1. _BigInt_ values are stringified as regular number instead of throwing a
-   TypeError (configurable).
-1. _Boxed primitives_ (e.g., `Number(5)`) are not unboxed and are handled as
-   regular object.
-
-Those are the only differences to `JSON.stringify()`. This is a side effect free
-variant and [`toJSON`][], [`replacer`][] and the [`spacer`][] work the same as
-with `JSON.stringify()`.
-
-## Performance / Benchmarks
-
-Currently this is by far the fastest known stable (deterministic) stringify
-implementation. This is especially important for big objects and TypedArrays.
-
-(Dell Precision 5540, i7-9850H CPU @ 2.60GHz, Node.js 16.11.1)
-
-```md
-simple:   simple object x 3,463,894 ops/sec ±0.44% (98 runs sampled)
-simple:   circular      x 1,236,007 ops/sec ±0.46% (99 runs sampled)
-simple:   deep          x 18,942 ops/sec ±0.41% (93 runs sampled)
-simple:   deep circular x 18,690 ops/sec ±0.72% (96 runs sampled)
-
-replacer:   simple object x 2,664,940 ops/sec ±0.31% (98 runs sampled)
-replacer:   circular      x 1,015,981 ops/sec ±0.09% (99 runs sampled)
-replacer:   deep          x 17,328 ops/sec ±0.38% (97 runs sampled)
-replacer:   deep circular x 17,071 ops/sec ±0.21% (98 runs sampled)
-
-array:   simple object x 3,869,608 ops/sec ±0.22% (98 runs sampled)
-array:   circular      x 3,853,943 ops/sec ±0.45% (96 runs sampled)
-array:   deep          x 3,563,227 ops/sec ±0.20% (100 runs sampled)
-array:   deep circular x 3,286,475 ops/sec ±0.07% (100 runs sampled)
-
-indentation:   simple object x 2,183,162 ops/sec ±0.66% (97 runs sampled)
-indentation:   circular      x 872,538 ops/sec ±0.57% (98 runs sampled)
-indentation:   deep          x 16,795 ops/sec ±0.48% (93 runs sampled)
-indentation:   deep circular x 16,443 ops/sec ±0.40% (97 runs sampled)
-```
-
-Comparing `safe-stable-stringify` with known alternatives:
-
-```md
-fast-json-stable-stringify x 18,765 ops/sec ±0.71% (94 runs sampled)
-json-stable-stringify x 13,870 ops/sec ±0.72% (94 runs sampled)
-fast-stable-stringify x 21,343 ops/sec ±0.33% (95 runs sampled)
-faster-stable-stringify x 17,707 ops/sec ±0.44% (97 runs sampled)
-json-stringify-deterministic x 11,208 ops/sec ±0.57% (98 runs sampled)
-fast-safe-stringify x 21,460 ops/sec ±0.75% (99 runs sampled)
-this x 30,367 ops/sec ±0.39% (96 runs sampled)
-
-The fastest is this
-```
-
-The `fast-safe-stringify` comparison uses the modules stable implementation.
-
-## Acknowledgements
-
-Sponsored by [MaibornWolff](https://www.maibornwolff.de/) and [nearForm](http://nearform.com)
-
-## License
-
-MIT
-
-[`replacer`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#The%20replacer%20parameter
-[`spacer`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#The%20space%20argument
-[`toJSON`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#toJSON()_behavior
-[JSON.stringify]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify

package/node_modules/safer-buffer/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2018 Nikita Skovoroda <chalkerx@gmail.com>
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.

package/node_modules/safer-buffer/Porting-Buffer.md

@@ -1,268 +0,0 @@
-# Porting to the Buffer.from/Buffer.alloc API
-
-<a id="overview"></a>
-## Overview
-
-- [Variant 1: Drop support for Node.js ≤ 4.4.x and 5.0.0 — 5.9.x.](#variant-1) (*recommended*)
-- [Variant 2: Use a polyfill](#variant-2)
-- [Variant 3: manual detection, with safeguards](#variant-3)
-
-### Finding problematic bits of code using grep
-
-Just run `grep -nrE '[^a-zA-Z](Slow)?Buffer\s*\(' --exclude-dir node_modules`.
-
-It will find all the potentially unsafe places in your own code (with some considerably unlikely
-exceptions).
-
-### Finding problematic bits of code using Node.js 8
-
-If you’re using Node.js ≥ 8.0.0 (which is recommended), Node.js exposes multiple options that help with finding the relevant pieces of code:
-
-- `--trace-warnings` will make Node.js show a stack trace for this warning and other warnings that are printed by Node.js.
-- `--trace-deprecation` does the same thing, but only for deprecation warnings.
-- `--pending-deprecation` will show more types of deprecation warnings. In particular, it will show the `Buffer()` deprecation warning, even on Node.js 8.
-
-You can set these flags using an environment variable:
-
-```console
-$ export NODE_OPTIONS='--trace-warnings --pending-deprecation'
-$ cat example.js
-'use strict';
-const foo = new Buffer('foo');
-$ node example.js
-(node:7147) [DEP0005] DeprecationWarning: The Buffer() and new Buffer() constructors are not recommended for use due to security and usability concerns. Please use the new Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() construction methods instead.
-    at showFlaggedDeprecation (buffer.js:127:13)
-    at new Buffer (buffer.js:148:3)
-    at Object.<anonymous> (/path/to/example.js:2:13)
-    [... more stack trace lines ...]
-```
-
-### Finding problematic bits of code using linters
-
-Eslint rules [no-buffer-constructor](https://eslint.org/docs/rules/no-buffer-constructor)
-or
-[node/no-deprecated-api](https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/no-deprecated-api.md)
-also find calls to deprecated `Buffer()` API. Those rules are included in some pre-sets.
-
-There is a drawback, though, that it doesn't always
-[work correctly](https://github.com/chalker/safer-buffer#why-not-safe-buffer) when `Buffer` is
-overriden e.g. with a polyfill, so recommended is a combination of this and some other method
-described above.
-
-<a id="variant-1"></a>
-## Variant 1: Drop support for Node.js ≤ 4.4.x and 5.0.0 — 5.9.x.
-
-This is the recommended solution nowadays that would imply only minimal overhead.
-
-The Node.js 5.x release line has been unsupported since July 2016, and the Node.js 4.x release line reaches its End of Life in April 2018 (→ [Schedule](https://github.com/nodejs/Release#release-schedule)). This means that these versions of Node.js will *not* receive any updates, even in case of security issues, so using these release lines should be avoided, if at all possible.
-
-What you would do in this case is to convert all `new Buffer()` or `Buffer()` calls to use `Buffer.alloc()` or `Buffer.from()`, in the following way:
-
-- For `new Buffer(number)`, replace it with `Buffer.alloc(number)`.
-- For `new Buffer(string)` (or `new Buffer(string, encoding)`), replace it with `Buffer.from(string)` (or `Buffer.from(string, encoding)`).
-- For all other combinations of arguments (these are much rarer), also replace `new Buffer(...arguments)` with `Buffer.from(...arguments)`.
-
-Note that `Buffer.alloc()` is also _faster_ on the current Node.js versions than
-`new Buffer(size).fill(0)`, which is what you would otherwise need to ensure zero-filling.
-
-Enabling eslint rule [no-buffer-constructor](https://eslint.org/docs/rules/no-buffer-constructor)
-or
-[node/no-deprecated-api](https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/no-deprecated-api.md)
-is recommended to avoid accidential unsafe Buffer API usage.
-
-There is also a [JSCodeshift codemod](https://github.com/joyeecheung/node-dep-codemod#dep005)
-for automatically migrating Buffer constructors to `Buffer.alloc()` or `Buffer.from()`.
-Note that it currently only works with cases where the arguments are literals or where the
-constructor is invoked with two arguments.
-
-_If you currently support those older Node.js versions and dropping them would be a semver-major change
-for you, or if you support older branches of your packages, consider using [Variant 2](#variant-2)
-or [Variant 3](#variant-3) on older branches, so people using those older branches will also receive
-the fix. That way, you will eradicate potential issues caused by unguarded Buffer API usage and
-your users will not observe a runtime deprecation warning when running your code on Node.js 10._
-
-<a id="variant-2"></a>
-## Variant 2: Use a polyfill
-
-Utilize [safer-buffer](https://www.npmjs.com/package/safer-buffer) as a polyfill to support older
-Node.js versions.
-
-You would take exacly the same steps as in [Variant 1](#variant-1), but with a polyfill
-`const Buffer = require('safer-buffer').Buffer` in all files where you use the new `Buffer` api.
-
-Make sure that you do not use old `new Buffer` API — in any files where the line above is added,
-using old `new Buffer()` API will _throw_. It will be easy to notice that in CI, though.
-
-Alternatively, you could use [buffer-from](https://www.npmjs.com/package/buffer-from) and/or
-[buffer-alloc](https://www.npmjs.com/package/buffer-alloc) [ponyfills](https://ponyfill.com/) —
-those are great, the only downsides being 4 deps in the tree and slightly more code changes to
-migrate off them (as you would be using e.g. `Buffer.from` under a different name). If you need only
-`Buffer.from` polyfilled — `buffer-from` alone which comes with no extra dependencies.
-
-_Alternatively, you could use [safe-buffer](https://www.npmjs.com/package/safe-buffer) — it also
-provides a polyfill, but takes a different approach which has
-[it's drawbacks](https://github.com/chalker/safer-buffer#why-not-safe-buffer). It will allow you
-to also use the older `new Buffer()` API in your code, though — but that's arguably a benefit, as
-it is problematic, can cause issues in your code, and will start emitting runtime deprecation
-warnings starting with Node.js 10._
-
-Note that in either case, it is important that you also remove all calls to the old Buffer
-API manually — just throwing in `safe-buffer` doesn't fix the problem by itself, it just provides
-a polyfill for the new API. I have seen people doing that mistake.
-
-Enabling eslint rule [no-buffer-constructor](https://eslint.org/docs/rules/no-buffer-constructor)
-or
-[node/no-deprecated-api](https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/no-deprecated-api.md)
-is recommended.
-
-_Don't forget to drop the polyfill usage once you drop support for Node.js < 4.5.0._
-
-<a id="variant-3"></a>
-## Variant 3 — manual detection, with safeguards
-
-This is useful if you create Buffer instances in only a few places (e.g. one), or you have your own
-wrapper around them.
-
-### Buffer(0)
-
-This special case for creating empty buffers can be safely replaced with `Buffer.concat([])`, which
-returns the same result all the way down to Node.js 0.8.x.
-
-### Buffer(notNumber)
-
-Before:
-
-```js
-var buf = new Buffer(notNumber, encoding);
-```
-
-After:
-
-```js
-var buf;
-if (Buffer.from && Buffer.from !== Uint8Array.from) {
-  buf = Buffer.from(notNumber, encoding);
-} else {
-  if (typeof notNumber === 'number')
-    throw new Error('The "size" argument must be of type number.');
-  buf = new Buffer(notNumber, encoding);
-}
-```
-
-`encoding` is optional.
-
-Note that the `typeof notNumber` before `new Buffer` is required (for cases when `notNumber` argument is not
-hard-coded) and _is not caused by the deprecation of Buffer constructor_ — it's exactly _why_ the
-Buffer constructor is deprecated. Ecosystem packages lacking this type-check caused numereous
-security issues — situations when unsanitized user input could end up in the `Buffer(arg)` create
-problems ranging from DoS to leaking sensitive information to the attacker from the process memory.
-
-When `notNumber` argument is hardcoded (e.g. literal `"abc"` or `[0,1,2]`), the `typeof` check can
-be omitted.
-
-Also note that using TypeScript does not fix this problem for you — when libs written in
-`TypeScript` are used from JS, or when user input ends up there — it behaves exactly as pure JS, as
-all type checks are translation-time only and are not present in the actual JS code which TS
-compiles to.
-
-### Buffer(number)
-
-For Node.js 0.10.x (and below) support:
-
-```js
-var buf;
-if (Buffer.alloc) {
-  buf = Buffer.alloc(number);
-} else {
-  buf = new Buffer(number);
-  buf.fill(0);
-}
-```
-
-Otherwise (Node.js ≥ 0.12.x):
-
-```js
-const buf = Buffer.alloc ? Buffer.alloc(number) : new Buffer(number).fill(0);
-```
-
-## Regarding Buffer.allocUnsafe
-
-Be extra cautious when using `Buffer.allocUnsafe`:
- * Don't use it if you don't have a good reason to
-   * e.g. you probably won't ever see a performance difference for small buffers, in fact, those
-     might be even faster with `Buffer.alloc()`,
-   * if your code is not in the hot code path — you also probably won't notice a difference,
-   * keep in mind that zero-filling minimizes the potential risks.
- * If you use it, make sure that you never return the buffer in a partially-filled state,
-   * if you are writing to it sequentially — always truncate it to the actuall written length
-
-Errors in handling buffers allocated with `Buffer.allocUnsafe` could result in various issues,
-ranged from undefined behaviour of your code to sensitive data (user input, passwords, certs)
-leaking to the remote attacker.
-
-_Note that the same applies to `new Buffer` usage without zero-filling, depending on the Node.js
-version (and lacking type checks also adds DoS to the list of potential problems)._
-
-<a id="faq"></a>
-## FAQ
-
-<a id="design-flaws"></a>
-### What is wrong with the `Buffer` constructor?
-
-The `Buffer` constructor could be used to create a buffer in many different ways:
-
-- `new Buffer(42)` creates a `Buffer` of 42 bytes. Before Node.js 8, this buffer contained
-  *arbitrary memory* for performance reasons, which could include anything ranging from
-  program source code to passwords and encryption keys.
-- `new Buffer('abc')` creates a `Buffer` that contains the UTF-8-encoded version of
-  the string `'abc'`. A second argument could specify another encoding: For example,
-  `new Buffer(string, 'base64')` could be used to convert a Base64 string into the original
-  sequence of bytes that it represents.
-- There are several other combinations of arguments.
-
-This meant that, in code like `var buffer = new Buffer(foo);`, *it is not possible to tell
-what exactly the contents of the generated buffer are* without knowing the type of `foo`.
-
-Sometimes, the value of `foo` comes from an external source. For example, this function
-could be exposed as a service on a web server, converting a UTF-8 string into its Base64 form:
-
-```
-function stringToBase64(req, res) {
-  // The request body should have the format of `{ string: 'foobar' }`
-  const rawBytes = new Buffer(req.body.string)
-  const encoded = rawBytes.toString('base64')
-  res.end({ encoded: encoded })
-}
-```
-
-Note that this code does *not* validate the type of `req.body.string`:
-
-- `req.body.string` is expected to be a string. If this is the case, all goes well.
-- `req.body.string` is controlled by the client that sends the request.
-- If `req.body.string` is the *number* `50`, the `rawBytes` would be 50 bytes:
-  - Before Node.js 8, the content would be uninitialized
-  - After Node.js 8, the content would be `50` bytes with the value `0`
-
-Because of the missing type check, an attacker could intentionally send a number
-as part of the request. Using this, they can either:
-
-- Read uninitialized memory. This **will** leak passwords, encryption keys and other
-  kinds of sensitive information. (Information leak)
-- Force the program to allocate a large amount of memory. For example, when specifying
-  `500000000` as the input value, each request will allocate 500MB of memory.
-  This can be used to either exhaust the memory available of a program completely
-  and make it crash, or slow it down significantly. (Denial of Service)
-
-Both of these scenarios are considered serious security issues in a real-world
-web server context.
-
-when using `Buffer.from(req.body.string)` instead, passing a number will always
-throw an exception instead, giving a controlled behaviour that can always be
-handled by the program.
-
-<a id="ecosystem-usage"></a>
-### The `Buffer()` constructor has been deprecated for a while. Is this really an issue?
-
-Surveys of code in the `npm` ecosystem have shown that the `Buffer()` constructor is still
-widely used. This includes new code, and overall usage of such code has actually been
-*increasing*.

package/node_modules/safer-buffer/Readme.md

@@ -1,156 +0,0 @@
-# safer-buffer [![travis][travis-image]][travis-url] [![npm][npm-image]][npm-url] [![javascript style guide][standard-image]][standard-url] [![Security Responsible Disclosure][secuirty-image]][secuirty-url]
-
-[travis-image]: https://travis-ci.org/ChALkeR/safer-buffer.svg?branch=master
-[travis-url]: https://travis-ci.org/ChALkeR/safer-buffer
-[npm-image]: https://img.shields.io/npm/v/safer-buffer.svg
-[npm-url]: https://npmjs.org/package/safer-buffer
-[standard-image]: https://img.shields.io/badge/code_style-standard-brightgreen.svg
-[standard-url]: https://standardjs.com
-[secuirty-image]: https://img.shields.io/badge/Security-Responsible%20Disclosure-green.svg
-[secuirty-url]: https://github.com/nodejs/security-wg/blob/master/processes/responsible_disclosure_template.md
-
-Modern Buffer API polyfill without footguns, working on Node.js from 0.8 to current.
-
-## How to use?
-
-First, port all `Buffer()` and `new Buffer()` calls to `Buffer.alloc()` and `Buffer.from()` API.
-
-Then, to achieve compatibility with outdated Node.js versions (`<4.5.0` and 5.x `<5.9.0`), use
-`const Buffer = require('safer-buffer').Buffer` in all files where you make calls to the new
-Buffer API. _Use `var` instead of `const` if you need that for your Node.js version range support._
-
-Also, see the
-[porting Buffer](https://github.com/ChALkeR/safer-buffer/blob/master/Porting-Buffer.md) guide.
-
-## Do I need it?
-
-Hopefully, not — dropping support for outdated Node.js versions should be fine nowdays, and that
-is the recommended path forward. You _do_ need to port to the `Buffer.alloc()` and `Buffer.from()`
-though.
-
-See the [porting guide](https://github.com/ChALkeR/safer-buffer/blob/master/Porting-Buffer.md)
-for a better description.
-
-## Why not [safe-buffer](https://npmjs.com/safe-buffer)?
-
-_In short: while `safe-buffer` serves as a polyfill for the new API, it allows old API usage and
-itself contains footguns._
-
-`safe-buffer` could be used safely to get the new API while still keeping support for older
-Node.js versions (like this module), but while analyzing ecosystem usage of the old Buffer API
-I found out that `safe-buffer` is itself causing problems in some cases.
-
-For example, consider the following snippet:
-
-```console
-$ cat example.unsafe.js
-console.log(Buffer(20))
-$ ./node-v6.13.0-linux-x64/bin/node example.unsafe.js
-<Buffer 0a 00 00 00 00 00 00 00 28 13 de 02 00 00 00 00 05 00 00 00>
-$ standard example.unsafe.js
-standard: Use JavaScript Standard Style (https://standardjs.com)
-  /home/chalker/repo/safer-buffer/example.unsafe.js:2:13: 'Buffer()' was deprecated since v6. Use 'Buffer.alloc()' or 'Buffer.from()' (use 'https://www.npmjs.com/package/safe-buffer' for '<4.5.0') instead.
-```
-
-This is allocates and writes to console an uninitialized chunk of memory.
-[standard](https://www.npmjs.com/package/standard) linter (among others) catch that and warn people
-to avoid using unsafe API.
-
-Let's now throw in `safe-buffer`!
-
-```console
-$ cat example.safe-buffer.js
-const Buffer = require('safe-buffer').Buffer
-console.log(Buffer(20))
-$ standard example.safe-buffer.js
-$ ./node-v6.13.0-linux-x64/bin/node example.safe-buffer.js
-<Buffer 08 00 00 00 00 00 00 00 28 58 01 82 fe 7f 00 00 00 00 00 00>
-```
-
-See the problem? Adding in `safe-buffer` _magically removes the lint warning_, but the behavior
-remains identiсal to what we had before, and when launched on Node.js 6.x LTS — this dumps out
-chunks of uninitialized memory.
-_And this code will still emit runtime warnings on Node.js 10.x and above._
-
-That was done by design. I first considered changing `safe-buffer`, prohibiting old API usage or
-emitting warnings on it, but that significantly diverges from `safe-buffer` design. After some
-discussion, it was decided to move my approach into a separate package, and _this is that separate
-package_.
-
-This footgun is not imaginary — I observed top-downloaded packages doing that kind of thing,
-«fixing» the lint warning by blindly including `safe-buffer` without any actual changes.
-
-Also in some cases, even if the API _was_ migrated to use of safe Buffer API — a random pull request
-can bring unsafe Buffer API usage back to the codebase by adding new calls — and that could go
-unnoticed even if you have a linter prohibiting that (becase of the reason stated above), and even
-pass CI. _I also observed that being done in popular packages._
-
-Some examples:
- * [webdriverio](https://github.com/webdriverio/webdriverio/commit/05cbd3167c12e4930f09ef7cf93b127ba4effae4#diff-124380949022817b90b622871837d56cR31)
-   (a module with 548 759 downloads/month),
- * [websocket-stream](https://github.com/maxogden/websocket-stream/commit/c9312bd24d08271687d76da0fe3c83493871cf61)
-   (218 288 d/m, fix in [maxogden/websocket-stream#142](https://github.com/maxogden/websocket-stream/pull/142)),
- * [node-serialport](https://github.com/node-serialport/node-serialport/commit/e8d9d2b16c664224920ce1c895199b1ce2def48c)
-   (113 138 d/m, fix in [node-serialport/node-serialport#1510](https://github.com/node-serialport/node-serialport/pull/1510)),
- * [karma](https://github.com/karma-runner/karma/commit/3d94b8cf18c695104ca195334dc75ff054c74eec)
-   (3 973 193 d/m, fix in [karma-runner/karma#2947](https://github.com/karma-runner/karma/pull/2947)),
- * [spdy-transport](https://github.com/spdy-http2/spdy-transport/commit/5375ac33f4a62a4f65bcfc2827447d42a5dbe8b1)
-   (5 970 727 d/m, fix in [spdy-http2/spdy-transport#53](https://github.com/spdy-http2/spdy-transport/pull/53)).
- * And there are a lot more over the ecosystem.
-
-I filed a PR at
-[mysticatea/eslint-plugin-node#110](https://github.com/mysticatea/eslint-plugin-node/pull/110) to
-partially fix that (for cases when that lint rule is used), but it is a semver-major change for
-linter rules and presets, so it would take significant time for that to reach actual setups.
-_It also hasn't been released yet (2018-03-20)._
-
-Also, `safer-buffer` discourages the usage of `.allocUnsafe()`, which is often done by a mistake.
-It still supports it with an explicit concern barier, by placing it under
-`require('safer-buffer/dangereous')`.
-
-## But isn't throwing bad?
-
-Not really. It's an error that could be noticed and fixed early, instead of causing havoc later like
-unguarded `new Buffer()` calls that end up receiving user input can do.
-
-This package affects only the files where `var Buffer = require('safer-buffer').Buffer` was done, so
-it is really simple to keep track of things and make sure that you don't mix old API usage with that.
-Also, CI should hint anything that you might have missed.
-
-New commits, if tested, won't land new usage of unsafe Buffer API this way.
-_Node.js 10.x also deals with that by printing a runtime depecation warning._
-
-### Would it affect third-party modules?
-
-No, unless you explicitly do an awful thing like monkey-patching or overriding the built-in `Buffer`.
-Don't do that.
-
-### But I don't want throwing…
-
-That is also fine!
-
-Also, it could be better in some cases when you don't comprehensive enough test coverage.
-
-In that case — just don't override `Buffer` and use
-`var SaferBuffer = require('safer-buffer').Buffer` instead.
-
-That way, everything using `Buffer` natively would still work, but there would be two drawbacks:
-
-* `Buffer.from`/`Buffer.alloc` won't be polyfilled — use `SaferBuffer.from` and
-  `SaferBuffer.alloc` instead.
-* You are still open to accidentally using the insecure deprecated API — use a linter to catch that.
-
-Note that using a linter to catch accidential `Buffer` constructor usage in this case is strongly
-recommended. `Buffer` is not overriden in this usecase, so linters won't get confused.
-
-## «Without footguns»?
-
-Well, it is still possible to do _some_ things with `Buffer` API, e.g. accessing `.buffer` property
-on older versions and duping things from there. You shouldn't do that in your code, probabably.
-
-The intention is to remove the most significant footguns that affect lots of packages in the
-ecosystem, and to do it in the proper way.
-
-Also, this package doesn't protect against security issues affecting some Node.js versions, so for
-usage in your own production code, it is still recommended to update to a Node.js version
-[supported by upstream](https://github.com/nodejs/release#release-schedule).