korext 0.1.0

package/node_modules/is-unicode-supported/readme.md

@@ -0,0 +1,35 @@
+# is-unicode-supported
+
+> Detect whether the terminal supports Unicode
+
+This can be useful to decide whether to use Unicode characters or fallback ASCII characters in command-line output.
+
+Note that the check is quite naive. It just assumes all non-Windows terminals support Unicode and hard-codes which Windows terminals that do support Unicode. However, I have been using this logic in some popular packages for years without problems.
+
+## Install
+
+```
+$ npm install is-unicode-supported
+```
+
+## Usage
+
+```js
+const isUnicodeSupported = require('is-unicode-supported');
+
+isUnicodeSupported();
+//=> true
+```
+
+## API
+
+### isUnicodeSupported()
+
+Returns a `boolean` for whether the terminal supports Unicode.
+
+## Related
+
+- [is-interactive](https://github.com/sindresorhus/is-interactive) - Check if stdout or stderr is interactive
+- [supports-color](https://github.com/chalk/supports-color) - Detect whether a terminal supports color
+- [figures](https://github.com/sindresorhus/figures) - Unicode symbols with Windows fallbacks
+- [log-symbols](https://github.com/sindresorhus/log-symbols) - Colored symbols for various log levels

package/node_modules/log-symbols/browser.js

@@ -0,0 +1,8 @@
+'use strict';
+
+module.exports = {
+	info: 'ℹ️',
+	success: '✅',
+	warning: '⚠️',
+	error: '❌️'
+};

package/node_modules/log-symbols/index.d.ts

@@ -0,0 +1,25 @@
+/**
+Colored symbols for various log levels.
+
+Includes fallbacks for Windows CMD which only supports a [limited character set](https://en.wikipedia.org/wiki/Code_page_437).
+
+@example
+```
+import logSymbols = require('log-symbols');
+
+console.log(logSymbols.success, 'Finished successfully!');
+// Terminals with Unicode support:     ✔ Finished successfully!
+// Terminals without Unicode support:  √ Finished successfully!
+```
+*/
+declare const logSymbols: {
+	readonly info: string;
+
+	readonly success: string;
+
+	readonly warning: string;
+
+	readonly error: string;
+};
+
+export = logSymbols;

package/node_modules/log-symbols/index.js

@@ -0,0 +1,19 @@
+'use strict';
+const chalk = require('chalk');
+const isUnicodeSupported = require('is-unicode-supported');
+
+const main = {
+	info: chalk.blue('ℹ'),
+	success: chalk.green('✔'),
+	warning: chalk.yellow('⚠'),
+	error: chalk.red('✖')
+};
+
+const fallback = {
+	info: chalk.blue('i'),
+	success: chalk.green('√'),
+	warning: chalk.yellow('‼'),
+	error: chalk.red('×')
+};
+
+module.exports = isUnicodeSupported() ? main : fallback;

package/node_modules/log-symbols/license

@@ -0,0 +1,9 @@
+MIT License
+
+Copyright (c) Sindre Sorhus <sindresorhus@gmail.com> (https://sindresorhus.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/log-symbols/package.json

@@ -0,0 +1,52 @@
+{
+	"name": "log-symbols",
+	"version": "4.1.0",
+	"description": "Colored symbols for various log levels. Example: `✔︎ Success`",
+	"license": "MIT",
+	"repository": "sindresorhus/log-symbols",
+	"funding": "https://github.com/sponsors/sindresorhus",
+	"author": {
+		"name": "Sindre Sorhus",
+		"email": "sindresorhus@gmail.com",
+		"url": "https://sindresorhus.com"
+	},
+	"engines": {
+		"node": ">=10"
+	},
+	"scripts": {
+		"test": "xo && ava && tsd"
+	},
+	"files": [
+		"index.js",
+		"index.d.ts",
+		"browser.js"
+	],
+	"keywords": [
+		"unicode",
+		"cli",
+		"cmd",
+		"command-line",
+		"characters",
+		"symbol",
+		"symbols",
+		"figure",
+		"figures",
+		"fallback",
+		"windows",
+		"log",
+		"logging",
+		"terminal",
+		"stdout"
+	],
+	"dependencies": {
+		"chalk": "^4.1.0",
+		"is-unicode-supported": "^0.1.0"
+	},
+	"devDependencies": {
+		"ava": "^2.4.0",
+		"strip-ansi": "^6.0.0",
+		"tsd": "^0.14.0",
+		"xo": "^0.38.2"
+	},
+	"browser": "browser.js"
+}

package/node_modules/log-symbols/readme.md

@@ -0,0 +1,51 @@
+# log-symbols
+
+<img src="screenshot.png" width="226" height="192" align="right">
+
+> Colored symbols for various log levels
+
+Includes fallbacks for Windows CMD which only supports a [limited character set](https://en.wikipedia.org/wiki/Code_page_437).
+
+## Install
+
+```
+$ npm install log-symbols
+```
+
+## Usage
+
+```js
+const logSymbols = require('log-symbols');
+
+console.log(logSymbols.success, 'Finished successfully!');
+// Terminals with Unicode support:     ✔ Finished successfully!
+// Terminals without Unicode support:  √ Finished successfully!
+```
+
+## API
+
+### logSymbols
+
+#### info
+#### success
+#### warning
+#### error
+
+## Related
+
+- [figures](https://github.com/sindresorhus/figures) - Unicode symbols with Windows CMD fallbacks
+- [py-log-symbols](https://github.com/ManrajGrover/py-log-symbols) - Python port
+- [log-symbols](https://github.com/palash25/log-symbols) - Ruby port
+- [guumaster/logsymbols](https://github.com/guumaster/logsymbols) - Golang port
+
+---
+
+<div align="center">
+	<b>
+		<a href="https://tidelift.com/subscription/pkg/npm-log-symbols?utm_source=npm-log-symbols&utm_medium=referral&utm_campaign=readme">Get professional support for this package with a Tidelift subscription</a>
+	</b>
+	<br>
+	<sub>
+		Tidelift helps make open source sustainable for maintainers while giving companies<br>assurances about security, maintenance, and licensing for their dependencies.
+	</sub>
+</div>

package/node_modules/lru-cache/LICENSE.md

@@ -0,0 +1,55 @@
+# Blue Oak Model License
+
+Version 1.0.0
+
+## Purpose
+
+This license gives everyone as much permission to work with
+this software as possible, while protecting contributors
+from liability.
+
+## Acceptance
+
+In order to receive this license, you must agree to its
+rules.  The rules of this license are both obligations
+under that agreement and conditions to your license.
+You must not do anything with this software that triggers
+a rule that you cannot or will not follow.
+
+## Copyright
+
+Each contributor licenses you to do everything with this
+software that would otherwise infringe that contributor's
+copyright in it.
+
+## Notices
+
+You must ensure that everyone who gets a copy of
+any part of this software from you, with or without
+changes, also gets the text of this license or a link to
+<https://blueoakcouncil.org/license/1.0.0>.
+
+## Excuse
+
+If anyone notifies you in writing that you have not
+complied with [Notices](#notices), you can keep your
+license by taking all practical steps to comply within 30
+days after the notice.  If you do not do so, your license
+ends immediately.
+
+## Patent
+
+Each contributor licenses you to do everything with this
+software that would otherwise infringe any patent claims
+they can license or become able to license.
+
+## Reliability
+
+No contributor can revoke this license.
+
+## No Liability
+
+***As far as the law allows, this software comes as is,
+without any warranty or condition, and no contributor
+will be liable to anyone for any damages related to this
+software or this license, under any kind of legal claim.***

package/node_modules/lru-cache/README.md

@@ -0,0 +1,383 @@
+# lru-cache
+
+A cache object that deletes the least-recently-used items.
+
+Specify a max number of the most recently used items that you
+want to keep, and this cache will keep that many of the most
+recently accessed items.
+
+This is not primarily a TTL cache, and does not make strong TTL
+guarantees. There is no preemptive pruning of expired items by
+default, but you _may_ set a TTL on the cache or on a single
+`set`. If you do so, it will treat expired items as missing, and
+delete them when fetched. If you are more interested in TTL
+caching than LRU caching, check out
+[@isaacs/ttlcache](http://npm.im/@isaacs/ttlcache).
+
+As of version 7, this is one of the most performant LRU
+implementations available in JavaScript, and supports a wide
+diversity of use cases. However, note that using some of the
+features will necessarily impact performance, by causing the
+cache to have to do more work. See the "Performance" section
+below.
+
+## Installation
+
+```bash
+npm install lru-cache --save
+```
+
+## Usage
+
+```js
+// hybrid module, either works
+import { LRUCache } from 'lru-cache'
+// or:
+const { LRUCache } = require('lru-cache')
+// or in minified form for web browsers:
+import { LRUCache } from 'http://unpkg.com/lru-cache@9/dist/mjs/index.min.mjs'
+
+// At least one of 'max', 'ttl', or 'maxSize' is required, to prevent
+// unsafe unbounded storage.
+//
+// In most cases, it's best to specify a max for performance, so all
+// the required memory allocation is done up-front.
+//
+// All the other options are optional, see the sections below for
+// documentation on what each one does.  Most of them can be
+// overridden for specific items in get()/set()
+const options = {
+  max: 500,
+
+  // for use with tracking overall storage size
+  maxSize: 5000,
+  sizeCalculation: (value, key) => {
+    return 1
+  },
+
+  // for use when you need to clean up something when objects
+  // are evicted from the cache
+  dispose: (value, key, reason) => {
+    freeFromMemoryOrWhatever(value)
+  },
+
+  // for use when you need to know that an item is being inserted
+  // note that this does NOT allow you to prevent the insertion,
+  // it just allows you to know about it.
+  onInsert: (value, key, reason) => {
+    logInsertionOrWhatever(key, value)
+  },
+
+  // how long to live in ms
+  ttl: 1000 * 60 * 5,
+
+  // return stale items before removing from cache?
+  allowStale: false,
+
+  updateAgeOnGet: false,
+  updateAgeOnHas: false,
+
+  // async method to use for cache.fetch(), for
+  // stale-while-revalidate type of behavior
+  fetchMethod: async (key, staleValue, { options, signal, context }) => {},
+}
+
+const cache = new LRUCache(options)
+
+cache.set('key', 'value')
+cache.get('key') // "value"
+
+// non-string keys ARE fully supported
+// but note that it must be THE SAME object, not
+// just a JSON-equivalent object.
+var someObject = { a: 1 }
+cache.set(someObject, 'a value')
+// Object keys are not toString()-ed
+cache.set('[object Object]', 'a different value')
+assert.equal(cache.get(someObject), 'a value')
+// A similar object with same keys/values won't work,
+// because it's a different object identity
+assert.equal(cache.get({ a: 1 }), undefined)
+
+cache.clear() // empty the cache
+```
+
+If you put more stuff in the cache, then less recently used items
+will fall out. That's what an LRU cache is.
+
+For full description of the API and all options, please see [the
+LRUCache typedocs](https://isaacs.github.io/node-lru-cache/)
+
+## Storage Bounds Safety
+
+This implementation aims to be as flexible as possible, within
+the limits of safe memory consumption and optimal performance.
+
+At initial object creation, storage is allocated for `max` items.
+If `max` is set to zero, then some performance is lost, and item
+count is unbounded. Either `maxSize` or `ttl` _must_ be set if
+`max` is not specified.
+
+If `maxSize` is set, then this creates a safe limit on the
+maximum storage consumed, but without the performance benefits of
+pre-allocation. When `maxSize` is set, every item _must_ provide
+a size, either via the `sizeCalculation` method provided to the
+constructor, or via a `size` or `sizeCalculation` option provided
+to `cache.set()`. The size of every item _must_ be a positive
+integer.
+
+If neither `max` nor `maxSize` are set, then `ttl` tracking must
+be enabled. Note that, even when tracking item `ttl`, items are
+_not_ preemptively deleted when they become stale, unless
+`ttlAutopurge` is enabled. Instead, they are only purged the
+next time the key is requested. Thus, if `ttlAutopurge`, `max`,
+and `maxSize` are all not set, then the cache will potentially
+grow unbounded.
+
+In this case, a warning is printed to standard error. Future
+versions may require the use of `ttlAutopurge` if `max` and
+`maxSize` are not specified.
+
+If you truly wish to use a cache that is bound _only_ by TTL
+expiration, consider using a `Map` object, and calling
+`setTimeout` to delete entries when they expire. It will perform
+much better than an LRU cache.
+
+Here is an implementation you may use, under the same
+[license](./LICENSE) as this package:
+
+```js
+// a storage-unbounded ttl cache that is not an lru-cache
+const cache = {
+  data: new Map(),
+  timers: new Map(),
+  set: (k, v, ttl) => {
+    if (cache.timers.has(k)) {
+      clearTimeout(cache.timers.get(k))
+    }
+    cache.timers.set(
+      k,
+      setTimeout(() => cache.delete(k), ttl),
+    )
+    cache.data.set(k, v)
+  },
+  get: k => cache.data.get(k),
+  has: k => cache.data.has(k),
+  delete: k => {
+    if (cache.timers.has(k)) {
+      clearTimeout(cache.timers.get(k))
+    }
+    cache.timers.delete(k)
+    return cache.data.delete(k)
+  },
+  clear: () => {
+    cache.data.clear()
+    for (const v of cache.timers.values()) {
+      clearTimeout(v)
+    }
+    cache.timers.clear()
+  },
+}
+```
+
+If that isn't to your liking, check out
+[@isaacs/ttlcache](http://npm.im/@isaacs/ttlcache).
+
+## Storing Undefined Values
+
+This cache never stores undefined values, as `undefined` is used
+internally in a few places to indicate that a key is not in the
+cache.
+
+You may call `cache.set(key, undefined)`, but this is just
+an alias for `cache.delete(key)`. Note that this has the effect
+that `cache.has(key)` will return _false_ after setting it to
+undefined.
+
+```js
+cache.set(myKey, undefined)
+cache.has(myKey) // false!
+```
+
+If you need to track `undefined` values, and still note that the
+key is in the cache, an easy workaround is to use a sigil object
+of your own.
+
+```js
+import { LRUCache } from 'lru-cache'
+const undefinedValue = Symbol('undefined')
+const cache = new LRUCache(...)
+const mySet = (key, value) =>
+  cache.set(key, value === undefined ? undefinedValue : value)
+const myGet = (key, value) => {
+  const v = cache.get(key)
+  return v === undefinedValue ? undefined : v
+}
+```
+
+## Performance
+
+As of January 2022, version 7 of this library is one of the most
+performant LRU cache implementations in JavaScript.
+
+Benchmarks can be extremely difficult to get right. In
+particular, the performance of set/get/delete operations on
+objects will vary _wildly_ depending on the type of key used. V8
+is highly optimized for objects with keys that are short strings,
+especially integer numeric strings. Thus any benchmark which
+tests _solely_ using numbers as keys will tend to find that an
+object-based approach performs the best.
+
+Note that coercing _anything_ to strings to use as object keys is
+unsafe, unless you can be 100% certain that no other type of
+value will be used. For example:
+
+```js
+const myCache = {}
+const set = (k, v) => (myCache[k] = v)
+const get = k => myCache[k]
+
+set({}, 'please hang onto this for me')
+set('[object Object]', 'oopsie')
+```
+
+Also beware of "Just So" stories regarding performance. Garbage
+collection of large (especially: deep) object graphs can be
+incredibly costly, with several "tipping points" where it
+increases exponentially. As a result, putting that off until
+later can make it much worse, and less predictable. If a library
+performs well, but only in a scenario where the object graph is
+kept shallow, then that won't help you if you are using large
+objects as keys.
+
+In general, when attempting to use a library to improve
+performance (such as a cache like this one), it's best to choose
+an option that will perform well in the sorts of scenarios where
+you'll actually use it.
+
+This library is optimized for repeated gets and minimizing
+eviction time, since that is the expected need of a LRU. Set
+operations are somewhat slower on average than a few other
+options, in part because of that optimization. It is assumed
+that you'll be caching some costly operation, ideally as rarely
+as possible, so optimizing set over get would be unwise.
+
+If performance matters to you:
+
+1. If it's at all possible to use small integer values as keys,
+   and you can guarantee that no other types of values will be
+   used as keys, then do that, and use a cache such as
+   [lru-fast](https://npmjs.com/package/lru-fast), or
+   [mnemonist's
+   LRUCache](https://yomguithereal.github.io/mnemonist/lru-cache)
+   which uses an Object as its data store.
+
+2. Failing that, if at all possible, use short non-numeric
+   strings (ie, less than 256 characters) as your keys, and use
+   [mnemonist's
+   LRUCache](https://yomguithereal.github.io/mnemonist/lru-cache).
+
+3. If the types of your keys will be anything else, especially
+   long strings, strings that look like floats, objects, or some
+   mix of types, or if you aren't sure, then this library will
+   work well for you.
+
+   If you do not need the features that this library provides
+   (like asynchronous fetching, a variety of TTL staleness
+   options, and so on), then [mnemonist's
+   LRUMap](https://yomguithereal.github.io/mnemonist/lru-map) is
+   a very good option, and just slightly faster than this module
+   (since it does considerably less).
+
+4. Do not use a `dispose` function, size tracking, or especially
+   ttl behavior, unless absolutely needed. These features are
+   convenient, and necessary in some use cases, and every attempt
+   has been made to make the performance impact minimal, but it
+   isn't nothing.
+
+## Testing
+
+When writing tests that involve TTL-related functionality, note
+that this module creates an internal reference to the global
+`performance` or `Date` objects at import time. If you import it
+statically at the top level, those references cannot be mocked or
+overridden in your test environment.
+
+To avoid this, dynamically import the package within your tests
+so that the references are captured after your mocks are applied.
+For example:
+
+```ts
+// ❌ Not recommended
+import { LRUCache } from 'lru-cache'
+// mocking timers, e.g. jest.useFakeTimers()
+
+// ✅ Recommended for TTL tests
+// mocking timers, e.g. jest.useFakeTimers()
+const { LRUCache } = await import('lru-cache')
+```
+
+This ensures that your mocked timers or time sources are
+respected when testing TTL behavior.
+
+Additionally, you can pass in a `perf` option when creating your
+LRUCache instance. This option accepts any object with a `now`
+method that returns a number.
+
+For example, this would be a very bare-bones time-mocking system
+you could use in your tests, without any particular test
+framework:
+
+```ts
+import { LRUCache } from 'lru-cache'
+
+let myClockTime = 0
+
+const cache = new LRUCache<string>({
+  max: 10,
+  ttl: 1000,
+  perf: {
+    now: () => myClockTime,
+  },
+})
+
+// run tests, updating myClockTime as needed
+```
+
+## Breaking Changes in Version 7
+
+This library changed to a different algorithm and internal data
+structure in version 7, yielding significantly better
+performance, albeit with some subtle changes as a result.
+
+If you were relying on the internals of LRUCache in version 6 or
+before, it probably will not work in version 7 and above.
+
+## Breaking Changes in Version 8
+
+- The `fetchContext` option was renamed to `context`, and may no
+  longer be set on the cache instance itself.
+- Rewritten in TypeScript, so pretty much all the types moved
+  around a lot.
+- The AbortController/AbortSignal polyfill was removed. For this
+  reason, **Node version 16.14.0 or higher is now required**.
+- Internal properties were moved to actual private class
+  properties.
+- Keys and values must not be `null` or `undefined`.
+- Minified export available at `'lru-cache/min'`, for both CJS
+  and MJS builds.
+
+## Breaking Changes in Version 9
+
+- Named export only, no default export.
+- AbortController polyfill returned, albeit with a warning when
+  used.
+
+## Breaking Changes in Version 10
+
+- `cache.fetch()` return type is now `Promise<V | undefined>`
+  instead of `Promise<V | void>`. This is an irrelevant change
+  practically speaking, but can require changes for TypeScript
+  users.
+
+For more info, see the [change log](CHANGELOG.md).