Refactor routing in App component to enhance navigation and improve error handling by integrating dynamic routes and updating the NotFound route.

node_modules/path-scurry/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.***

node_modules/path-scurry/README.md

@@ -0,0 +1,636 @@
+# path-scurry
+
+Extremely high performant utility for building tools that read
+the file system, minimizing filesystem and path string munging
+operations to the greatest degree possible.
+
+## Ugh, yet another file traversal thing on npm?
+
+Yes. None of the existing ones gave me exactly what I wanted.
+
+## Well what is it you wanted?
+
+While working on [glob](http://npm.im/glob), I found that I
+needed a module to very efficiently manage the traversal over a
+folder tree, such that:
+
+1. No `readdir()` or `stat()` would ever be called on the same
+   file or directory more than one time.
+2. No `readdir()` calls would be made if we can be reasonably
+   sure that the path is not a directory. (Ie, a previous
+   `readdir()` or `stat()` covered the path, and
+   `ent.isDirectory()` is false.)
+3. `path.resolve()`, `dirname()`, `basename()`, and other
+   string-parsing/munging operations are be minimized. This means
+   it has to track "provisional" child nodes that may not exist
+   (and if we find that they _don't_ exist, store that
+   information as well, so we don't have to ever check again).
+4. The API is not limited to use as a stream/iterator/etc. There
+   are many cases where an API like node's `fs` is preferrable.
+5. It's more important to prevent excess syscalls than to be up
+   to date, but it should be smart enough to know what it
+   _doesn't_ know, and go get it seamlessly when requested.
+6. Do not blow up the JS heap allocation if operating on a
+   directory with a huge number of entries.
+7. Handle all the weird aspects of Windows paths, like UNC paths
+   and drive letters and wrongway slashes, so that the consumer
+   can return canonical platform-specific paths without having to
+   parse or join or do any error-prone string munging.
+
+## PERFORMANCE
+
+JavaScript people throw around the word "blazing" a lot. I hope
+that this module doesn't blaze anyone. But it does go very fast,
+in the cases it's optimized for, if used properly.
+
+PathScurry provides ample opportunities to get extremely good
+performance, as well as several options to trade performance for
+convenience.
+
+Benchmarks can be run by executing `npm run bench`.
+
+As is always the case, doing more means going slower, doing less
+means going faster, and there are trade offs between speed and
+memory usage.
+
+PathScurry makes heavy use of [LRUCache](http://npm.im/lru-cache)
+to efficiently cache whatever it can, and `Path` objects remain
+in the graph for the lifetime of the walker, so repeated calls
+with a single PathScurry object will be extremely fast. However,
+adding items to a cold cache means "doing more", so in those
+cases, we pay a price. Nothing is free, but every effort has been
+made to reduce costs wherever possible.
+
+Also, note that a "cache as long as possible" approach means that
+changes to the filesystem may not be reflected in the results of
+repeated PathScurry operations.
+
+For resolving string paths, `PathScurry` ranges from 5-50 times
+faster than `path.resolve` on repeated resolutions, but around
+100 to 1000 times _slower_ on the first resolution. If your
+program is spending a lot of time resolving the _same_ paths
+repeatedly (like, thousands or millions of times), then this can
+be beneficial. But both implementations are pretty fast, and
+speeding up an infrequent operation from 4µs to 400ns is not
+going to move the needle on your app's performance.
+
+For walking file system directory trees, a lot depends on how
+often a given PathScurry object will be used, and also on the
+walk method used.
+
+With default settings on a folder tree of 100,000 items,
+consisting of around a 10-to-1 ratio of normal files to
+directories, PathScurry performs comparably to
+[@nodelib/fs.walk](http://npm.im/@nodelib/fs.walk), which is the
+fastest and most reliable file system walker I could find. As far
+as I can tell, it's almost impossible to go much faster in a
+Node.js program, just based on how fast you can push syscalls out
+to the fs thread pool.
+
+On my machine, that is about 1000-1200 completed walks per second
+for async or stream walks, and around 500-600 walks per second
+synchronously.
+
+In the warm cache state, PathScurry's performance increases
+around 4x for async `for await` iteration, 10-15x faster for
+streams and synchronous `for of` iteration, and anywhere from 30x
+to 80x faster for the rest.
+
+```
+# walk 100,000 fs entries, 10/1 file/dir ratio
+# operations / ms
+ New PathScurry object  |  Reuse PathScurry object
+     stream:  1112.589  |  13974.917
+sync stream:   492.718  |  15028.343
+ async walk:  1095.648  |  32706.395
+  sync walk:   527.632  |  46129.772
+ async iter:  1288.821  |   5045.510
+  sync iter:   498.496  |  17920.746
+```
+
+A hand-rolled walk calling `entry.readdir()` and recursing
+through the entries can benefit even more from caching, with
+greater flexibility and without the overhead of streams or
+generators.
+
+The cold cache state is still limited by the costs of file system
+operations, but with a warm cache, the only bottleneck is CPU
+speed and VM optimizations. Of course, in that case, some care
+must be taken to ensure that you don't lose performance as a
+result of silly mistakes, like calling `readdir()` on entries
+that you know are not directories.
+
+```
+# manual recursive iteration functions
+      cold cache  |  warm cache
+async:  1164.901  |  17923.320
+   cb:  1101.127  |  40999.344
+zalgo:  1082.240  |  66689.936
+ sync:   526.935  |  87097.591
+```
+
+In this case, the speed improves by around 10-20x in the async
+case, 40x in the case of using `entry.readdirCB` with protections
+against synchronous callbacks, and 50-100x with callback
+deferrals disabled, and _several hundred times faster_ for
+synchronous iteration.
+
+If you can think of a case that is not covered in these
+benchmarks, or an implementation that performs significantly
+better than PathScurry, please [let me
+know](https://github.com/isaacs/path-scurry/issues).
+
+## USAGE
+
+```ts
+// hybrid module, load with either method
+import { PathScurry, Path } from 'path-scurry'
+// or:
+const { PathScurry, Path } = require('path-scurry')
+
+// very simple example, say we want to find and
+// delete all the .DS_Store files in a given path
+// note that the API is very similar to just a
+// naive walk with fs.readdir()
+import { unlink } from 'fs/promises'
+
+// easy way, iterate over the directory and do the thing
+const pw = new PathScurry(process.cwd())
+for await (const entry of pw) {
+  if (entry.isFile() && entry.name === '.DS_Store') {
+    unlink(entry.fullpath())
+  }
+}
+
+// here it is as a manual recursive method
+const walk = async (entry: Path) => {
+  const promises: Promise<any> = []
+  // readdir doesn't throw on non-directories, it just doesn't
+  // return any entries, to save stack trace costs.
+  // Items are returned in arbitrary unsorted order
+  for (const child of await pw.readdir(entry)) {
+    // each child is a Path object
+    if (child.name === '.DS_Store' && child.isFile()) {
+      // could also do pw.resolve(entry, child.name),
+      // just like fs.readdir walking, but .fullpath is
+      // a *slightly* more efficient shorthand.
+      promises.push(unlink(child.fullpath()))
+    } else if (child.isDirectory()) {
+      promises.push(walk(child))
+    }
+  }
+  return Promise.all(promises)
+}
+
+walk(pw.cwd).then(() => {
+  console.log('all .DS_Store files removed')
+})
+
+const pw2 = new PathScurry('/a/b/c') // pw2.cwd is the Path for /a/b/c
+const relativeDir = pw2.cwd.resolve('../x') // Path entry for '/a/b/x'
+const relative2 = pw2.cwd.resolve('/a/b/d/../x') // same path, same entry
+assert.equal(relativeDir, relative2)
+```
+
+## API
+
+[Full TypeDoc API](https://isaacs.github.io/path-scurry)
+
+There are platform-specific classes exported, but for the most
+part, the default `PathScurry` and `Path` exports are what you
+most likely need, unless you are testing behavior for other
+platforms.
+
+Intended public API is documented here, but the full
+documentation does include internal types, which should not be
+accessed directly.
+
+### Interface `PathScurryOpts`
+
+The type of the `options` argument passed to the `PathScurry`
+constructor.
+
+- `nocase`: Boolean indicating that file names should be compared
+  case-insensitively. Defaults to `true` on darwin and win32
+  implementations, `false` elsewhere.
+
+  **Warning** Performing case-insensitive matching on a
+  case-sensitive filesystem will result in occasionally very
+  bizarre behavior. Performing case-sensitive matching on a
+  case-insensitive filesystem may negatively impact performance.
+
+- `childrenCacheSize`: Number of child entries to cache, in order
+  to speed up `resolve()` and `readdir()` calls. Defaults to
+  `16 * 1024` (ie, `16384`).
+
+  Setting it to a higher value will run the risk of JS heap
+  allocation errors on large directory trees. Setting it to `256`
+  or smaller will significantly reduce the construction time and
+  data consumption overhead, but with the downside of operations
+  being slower on large directory trees. Setting it to `0` will
+  mean that effectively no operations are cached, and this module
+  will be roughly the same speed as `fs` for file system
+  operations, and _much_ slower than `path.resolve()` for
+  repeated path resolution.
+
+- `fs` An object that will be used to override the default `fs`
+  methods. Any methods that are not overridden will use Node's
+  built-in implementations.
+
+  - lstatSync
+  - readdir (callback `withFileTypes` Dirent variant, used for
+    readdirCB and most walks)
+  - readdirSync
+  - readlinkSync
+  - realpathSync
+  - promises: Object containing the following async methods:
+    - lstat
+    - readdir (Dirent variant only)
+    - readlink
+    - realpath
+
+### Interface `WalkOptions`
+
+The options object that may be passed to all walk methods.
+
+- `withFileTypes`: Boolean, default true. Indicates that `Path`
+  objects should be returned. Set to `false` to get string paths
+  instead.
+- `follow`: Boolean, default false. Attempt to read directory
+  entries from symbolic links. Otherwise, only actual directories
+  are traversed. Regardless of this setting, a given target path
+  will only ever be walked once, meaning that a symbolic link to
+  a previously traversed directory will never be followed.
+
+  Setting this imposes a slight performance penalty, because
+  `readlink` must be called on all symbolic links encountered, in
+  order to avoid infinite cycles.
+
+- `filter`: Function `(entry: Path) => boolean`. If provided,
+  will prevent the inclusion of any entry for which it returns a
+  falsey value. This will not prevent directories from being
+  traversed if they do not pass the filter, though it will
+  prevent the directories themselves from being included in the
+  results. By default, if no filter is provided, then all entries
+  are included in the results.
+- `walkFilter`: Function `(entry: Path) => boolean`. If provided,
+  will prevent the traversal of any directory (or in the case of
+  `follow:true` symbolic links to directories) for which the
+  function returns false. This will not prevent the directories
+  themselves from being included in the result set. Use `filter`
+  for that.
+
+Note that TypeScript return types will only be inferred properly
+from static analysis if the `withFileTypes` option is omitted, or
+a constant `true` or `false` value.
+
+### Class `PathScurry`
+
+The main interface. Defaults to an appropriate class based on the
+current platform.
+
+Use `PathScurryWin32`, `PathScurryDarwin`, or `PathScurryPosix`
+if implementation-specific behavior is desired.
+
+All walk methods may be called with a `WalkOptions` argument to
+walk over the object's current working directory with the
+supplied options.
+
+#### `async pw.walk(entry?: string | Path | WalkOptions, opts?: WalkOptions)`
+
+Walk the directory tree according to the options provided,
+resolving to an array of all entries found.
+
+#### `pw.walkSync(entry?: string | Path | WalkOptions, opts?: WalkOptions)`
+
+Walk the directory tree according to the options provided,
+returning an array of all entries found.
+
+#### `pw.iterate(entry?: string | Path | WalkOptions, opts?: WalkOptions)`
+
+Iterate over the directory asynchronously, for use with `for
+await of`. This is also the default async iterator method.
+
+#### `pw.iterateSync(entry?: string | Path | WalkOptions, opts?: WalkOptions)`
+
+Iterate over the directory synchronously, for use with `for of`.
+This is also the default sync iterator method.
+
+#### `pw.stream(entry?: string | Path | WalkOptions, opts?: WalkOptions)`
+
+Return a [Minipass](http://npm.im/minipass) stream that emits
+each entry or path string in the walk. Results are made available
+asynchronously.
+
+#### `pw.streamSync(entry?: string | Path | WalkOptions, opts?: WalkOptions)`
+
+Return a [Minipass](http://npm.im/minipass) stream that emits
+each entry or path string in the walk. Results are made available
+synchronously, meaning that the walk will complete in a single
+tick if the stream is fully consumed.
+
+#### `pw.cwd`
+
+Path object representing the current working directory for the
+PathScurry.
+
+#### `pw.chdir(path: string)`
+
+Set the new effective current working directory for the scurry
+object, so that `path.relative()` and `path.relativePosix()`
+return values relative to the new cwd path.
+
+#### `pw.depth(path?: Path | string): number`
+
+Return the depth of the specified path (or the PathScurry cwd)
+within the directory tree.
+
+Root entries have a depth of `0`.
+
+#### `pw.resolve(...paths: string[])`
+
+Caching `path.resolve()`.
+
+Significantly faster than `path.resolve()` if called repeatedly
+with the same paths. Significantly slower otherwise, as it builds
+out the cached Path entries.
+
+To get a `Path` object resolved from the `PathScurry`, use
+`pw.cwd.resolve(path)`. Note that `Path.resolve` only takes a
+single string argument, not multiple.
+
+#### `pw.resolvePosix(...paths: string[])`
+
+Caching `path.resolve()`, but always using posix style paths.
+
+This is identical to `pw.resolve(...paths)` on posix systems (ie,
+everywhere except Windows).
+
+On Windows, it returns the full absolute UNC path using `/`
+separators. Ie, instead of `'C:\\foo\\bar`, it would return
+`//?/C:/foo/bar`.
+
+#### `pw.relative(path: string | Path): string`
+
+Return the relative path from the PathWalker cwd to the supplied
+path string or entry.
+
+If the nearest common ancestor is the root, then an absolute path
+is returned.
+
+#### `pw.relativePosix(path: string | Path): string`
+
+Return the relative path from the PathWalker cwd to the supplied
+path string or entry, using `/` path separators.
+
+If the nearest common ancestor is the root, then an absolute path
+is returned.
+
+On posix platforms (ie, all platforms except Windows), this is
+identical to `pw.relative(path)`.
+
+On Windows systems, it returns the resulting string as a
+`/`-delimited path. If an absolute path is returned (because the
+target does not share a common ancestor with `pw.cwd`), then a
+full absolute UNC path will be returned. Ie, instead of
+`'C:\\foo\\bar`, it would return `//?/C:/foo/bar`.
+
+#### `pw.basename(path: string | Path): string`
+
+Return the basename of the provided string or Path.
+
+#### `pw.dirname(path: string | Path): string`
+
+Return the parent directory of the supplied string or Path.
+
+#### `async pw.readdir(dir = pw.cwd, opts = { withFileTypes: true })`
+
+Read the directory and resolve to an array of strings if
+`withFileTypes` is explicitly set to `false` or Path objects
+otherwise.
+
+Can be called as `pw.readdir({ withFileTypes: boolean })` as
+well.
+
+Returns `[]` if no entries are found, or if any error occurs.
+
+Note that TypeScript return types will only be inferred properly
+from static analysis if the `withFileTypes` option is omitted, or
+a constant `true` or `false` value.
+
+#### `pw.readdirSync(dir = pw.cwd, opts = { withFileTypes: true })`
+
+Synchronous `pw.readdir()`
+
+#### `async pw.readlink(link = pw.cwd, opts = { withFileTypes: false })`
+
+Call `fs.readlink` on the supplied string or Path object, and
+return the result.
+
+Can be called as `pw.readlink({ withFileTypes: boolean })` as
+well.
+
+Returns `undefined` if any error occurs (for example, if the
+argument is not a symbolic link), or a `Path` object if
+`withFileTypes` is explicitly set to `true`, or a string
+otherwise.
+
+Note that TypeScript return types will only be inferred properly
+from static analysis if the `withFileTypes` option is omitted, or
+a constant `true` or `false` value.
+
+#### `pw.readlinkSync(link = pw.cwd, opts = { withFileTypes: false })`
+
+Synchronous `pw.readlink()`
+
+#### `async pw.lstat(entry = pw.cwd)`
+
+Call `fs.lstat` on the supplied string or Path object, and fill
+in as much information as possible, returning the updated `Path`
+object.
+
+Returns `undefined` if the entry does not exist, or if any error
+is encountered.
+
+Note that some `Stats` data (such as `ino`, `dev`, and `mode`)
+will not be supplied. For those things, you'll need to call
+`fs.lstat` yourself.
+
+#### `pw.lstatSync(entry = pw.cwd)`
+
+Synchronous `pw.lstat()`
+
+#### `pw.realpath(entry = pw.cwd, opts = { withFileTypes: false })`
+
+Call `fs.realpath` on the supplied string or Path object, and
+return the realpath if available.
+
+Returns `undefined` if any error occurs.
+
+May be called as `pw.realpath({ withFileTypes: boolean })` to run
+on `pw.cwd`.
+
+#### `pw.realpathSync(entry = pw.cwd, opts = { withFileTypes: false })`
+
+Synchronous `pw.realpath()`
+
+### Class `Path` implements [fs.Dirent](https://nodejs.org/docs/latest/api/fs.html#class-fsdirent)
+
+Object representing a given path on the filesystem, which may or
+may not exist.
+
+Note that the actual class in use will be either `PathWin32` or
+`PathPosix`, depending on the implementation of `PathScurry` in
+use. They differ in the separators used to split and join path
+strings, and the handling of root paths.
+
+In `PathPosix` implementations, paths are split and joined using
+the `'/'` character, and `'/'` is the only root path ever in use.
+
+In `PathWin32` implementations, paths are split using either
+`'/'` or `'\\'` and joined using `'\\'`, and multiple roots may
+be in use based on the drives and UNC paths encountered. UNC
+paths such as `//?/C:/` that identify a drive letter, will be
+treated as an alias for the same root entry as their associated
+drive letter (in this case `'C:\\'`).
+
+#### `path.name`
+
+Name of this file system entry.
+
+**Important**: _always_ test the path name against any test
+string using the `isNamed` method, and not by directly comparing
+this string. Otherwise, unicode path strings that the system sees
+as identical will not be properly treated as the same path,
+leading to incorrect behavior and possible security issues.
+
+#### `path.isNamed(name: string): boolean`
+
+Return true if the path is a match for the given path name. This
+handles case sensitivity and unicode normalization.
+
+Note: even on case-sensitive systems, it is **not** safe to test
+the equality of the `.name` property to determine whether a given
+pathname matches, due to unicode normalization mismatches.
+
+Always use this method instead of testing the `path.name`
+property directly.
+
+#### `path.isCWD`
+
+Set to true if this `Path` object is the current working
+directory of the `PathScurry` collection that contains it.
+
+#### `path.getType()`
+
+Returns the type of the Path object, `'File'`, `'Directory'`,
+etc.
+
+#### `path.isType(t: type)`
+
+Returns true if `is{t}()` returns true.
+
+For example, `path.isType('Directory')` is equivalent to
+`path.isDirectory()`.
+
+#### `path.depth()`
+
+Return the depth of the Path entry within the directory tree.
+Root paths have a depth of `0`.
+
+#### `path.fullpath()`
+
+The fully resolved path to the entry.
+
+#### `path.fullpathPosix()`
+
+The fully resolved path to the entry, using `/` separators.
+
+On posix systems, this is identical to `path.fullpath()`. On
+windows, this will return a fully resolved absolute UNC path
+using `/` separators. Eg, instead of `'C:\\foo\\bar'`, it will
+return `'//?/C:/foo/bar'`.
+
+#### `path.isFile()`, `path.isDirectory()`, etc.
+
+Same as the identical `fs.Dirent.isX()` methods.
+
+#### `path.isUnknown()`
+
+Returns true if the path's type is unknown. Always returns true
+when the path is known to not exist.
+
+#### `path.resolve(p: string)`
+
+Return a `Path` object associated with the provided path string
+as resolved from the current Path object.
+
+#### `path.relative(): string`
+
+Return the relative path from the PathWalker cwd to the supplied
+path string or entry.
+
+If the nearest common ancestor is the root, then an absolute path
+is returned.
+
+#### `path.relativePosix(): string`
+
+Return the relative path from the PathWalker cwd to the supplied
+path string or entry, using `/` path separators.
+
+If the nearest common ancestor is the root, then an absolute path
+is returned.
+
+On posix platforms (ie, all platforms except Windows), this is
+identical to `pw.relative(path)`.
+
+On Windows systems, it returns the resulting string as a
+`/`-delimited path. If an absolute path is returned (because the
+target does not share a common ancestor with `pw.cwd`), then a
+full absolute UNC path will be returned. Ie, instead of
+`'C:\\foo\\bar`, it would return `//?/C:/foo/bar`.
+
+#### `async path.readdir()`
+
+Return an array of `Path` objects found by reading the associated
+path entry.
+
+If path is not a directory, or if any error occurs, returns `[]`,
+and marks all children as provisional and non-existent.
+
+#### `path.readdirSync()`
+
+Synchronous `path.readdir()`
+
+#### `async path.readlink()`
+
+Return the `Path` object referenced by the `path` as a symbolic
+link.
+
+If the `path` is not a symbolic link, or any error occurs,
+returns `undefined`.
+
+#### `path.readlinkSync()`
+
+Synchronous `path.readlink()`
+
+#### `async path.lstat()`
+
+Call `lstat` on the path object, and fill it in with details
+determined.
+
+If path does not exist, or any other error occurs, returns
+`undefined`, and marks the path as "unknown" type.
+
+#### `path.lstatSync()`
+
+Synchronous `path.lstat()`
+
+#### `async path.realpath()`
+
+Call `realpath` on the path, and return a Path object
+corresponding to the result, or `undefined` if any error occurs.
+
+#### `path.realpathSync()`
+
+Synchornous `path.realpath()`

node_modules/path-scurry/dist/commonjs/package.json

@@ -0,0 +1,3 @@
+{
+  "type": "commonjs"
+}

node_modules/path-scurry/dist/esm/package.json

@@ -0,0 +1,3 @@
+{
+  "type": "module"
+}

node_modules/path-scurry/node_modules/lru-cache/LICENSE

@@ -0,0 +1,15 @@
+The ISC License
+
+Copyright (c) 2010-2023 Isaac Z. Schlueter and Contributors
+
+Permission to use, copy, modify, and/or distribute this software for any
+purpose with or without fee is hereby granted, provided that the above
+copyright notice and this permission notice appear in all copies.
+
+THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR
+IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

node_modules/path-scurry/node_modules/lru-cache/README.md

@@ -0,0 +1,331 @@
+# 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) => {
+    freeFromMemoryOrWhatever(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.
+
+## 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).

node_modules/path-scurry/node_modules/lru-cache/dist/commonjs/package.json

@@ -0,0 +1,3 @@
+{
+  "type": "commonjs"
+}

node_modules/path-scurry/node_modules/lru-cache/dist/esm/package.json

@@ -0,0 +1,3 @@
+{
+  "type": "module"
+}

node_modules/path-scurry/node_modules/lru-cache/package.json

@@ -0,0 +1,116 @@
+{
+  "name": "lru-cache",
+  "publishConfig": {
+    "tag": "legacy-v10"
+  },
+  "description": "A cache object that deletes the least-recently-used items.",
+  "version": "10.4.3",
+  "author": "Isaac Z. Schlueter <i@izs.me>",
+  "keywords": [
+    "mru",
+    "lru",
+    "cache"
+  ],
+  "sideEffects": false,
+  "scripts": {
+    "build": "npm run prepare",
+    "prepare": "tshy && bash fixup.sh",
+    "pretest": "npm run prepare",
+    "presnap": "npm run prepare",
+    "test": "tap",
+    "snap": "tap",
+    "preversion": "npm test",
+    "postversion": "npm publish",
+    "prepublishOnly": "git push origin --follow-tags",
+    "format": "prettier --write .",
+    "typedoc": "typedoc --tsconfig ./.tshy/esm.json ./src/*.ts",
+    "benchmark-results-typedoc": "bash scripts/benchmark-results-typedoc.sh",
+    "prebenchmark": "npm run prepare",
+    "benchmark": "make -C benchmark",
+    "preprofile": "npm run prepare",
+    "profile": "make -C benchmark profile"
+  },
+  "main": "./dist/commonjs/index.js",
+  "types": "./dist/commonjs/index.d.ts",
+  "tshy": {
+    "exports": {
+      ".": "./src/index.ts",
+      "./min": {
+        "import": {
+          "types": "./dist/esm/index.d.ts",
+          "default": "./dist/esm/index.min.js"
+        },
+        "require": {
+          "types": "./dist/commonjs/index.d.ts",
+          "default": "./dist/commonjs/index.min.js"
+        }
+      }
+    }
+  },
+  "repository": {
+    "type": "git",
+    "url": "git://github.com/isaacs/node-lru-cache.git"
+  },
+  "devDependencies": {
+    "@types/node": "^20.2.5",
+    "@types/tap": "^15.0.6",
+    "benchmark": "^2.1.4",
+    "esbuild": "^0.17.11",
+    "eslint-config-prettier": "^8.5.0",
+    "marked": "^4.2.12",
+    "mkdirp": "^2.1.5",
+    "prettier": "^2.6.2",
+    "tap": "^20.0.3",
+    "tshy": "^2.0.0",
+    "tslib": "^2.4.0",
+    "typedoc": "^0.25.3",
+    "typescript": "^5.2.2"
+  },
+  "license": "ISC",
+  "files": [
+    "dist"
+  ],
+  "prettier": {
+    "semi": false,
+    "printWidth": 70,
+    "tabWidth": 2,
+    "useTabs": false,
+    "singleQuote": true,
+    "jsxSingleQuote": false,
+    "bracketSameLine": true,
+    "arrowParens": "avoid",
+    "endOfLine": "lf"
+  },
+  "tap": {
+    "node-arg": [
+      "--expose-gc"
+    ],
+    "plugin": [
+      "@tapjs/clock"
+    ]
+  },
+  "exports": {
+    ".": {
+      "import": {
+        "types": "./dist/esm/index.d.ts",
+        "default": "./dist/esm/index.js"
+      },
+      "require": {
+        "types": "./dist/commonjs/index.d.ts",
+        "default": "./dist/commonjs/index.js"
+      }
+    },
+    "./min": {
+      "import": {
+        "types": "./dist/esm/index.d.ts",
+        "default": "./dist/esm/index.min.js"
+      },
+      "require": {
+        "types": "./dist/commonjs/index.d.ts",
+        "default": "./dist/commonjs/index.min.js"
+      }
+    }
+  },
+  "type": "module",
+  "module": "./dist/esm/index.js"
+}

node_modules/path-scurry/package.json

@@ -0,0 +1,89 @@
+{
+  "name": "path-scurry",
+  "version": "1.11.1",
+  "description": "walk paths fast and efficiently",
+  "author": "Isaac Z. Schlueter <i@izs.me> (https://blog.izs.me)",
+  "main": "./dist/commonjs/index.js",
+  "type": "module",
+  "exports": {
+    "./package.json": "./package.json",
+    ".": {
+      "import": {
+        "types": "./dist/esm/index.d.ts",
+        "default": "./dist/esm/index.js"
+      },
+      "require": {
+        "types": "./dist/commonjs/index.d.ts",
+        "default": "./dist/commonjs/index.js"
+      }
+    }
+  },
+  "files": [
+    "dist"
+  ],
+  "license": "BlueOak-1.0.0",
+  "scripts": {
+    "preversion": "npm test",
+    "postversion": "npm publish",
+    "prepublishOnly": "git push origin --follow-tags",
+    "prepare": "tshy",
+    "pretest": "npm run prepare",
+    "presnap": "npm run prepare",
+    "test": "tap",
+    "snap": "tap",
+    "format": "prettier --write . --loglevel warn",
+    "typedoc": "typedoc --tsconfig tsconfig-esm.json ./src/*.ts",
+    "bench": "bash ./scripts/bench.sh"
+  },
+  "prettier": {
+    "experimentalTernaries": true,
+    "semi": false,
+    "printWidth": 75,
+    "tabWidth": 2,
+    "useTabs": false,
+    "singleQuote": true,
+    "jsxSingleQuote": false,
+    "bracketSameLine": true,
+    "arrowParens": "avoid",
+    "endOfLine": "lf"
+  },
+  "devDependencies": {
+    "@nodelib/fs.walk": "^1.2.8",
+    "@types/node": "^20.12.11",
+    "c8": "^7.12.0",
+    "eslint-config-prettier": "^8.6.0",
+    "mkdirp": "^3.0.0",
+    "prettier": "^3.2.5",
+    "rimraf": "^5.0.1",
+    "tap": "^18.7.2",
+    "ts-node": "^10.9.2",
+    "tshy": "^1.14.0",
+    "typedoc": "^0.25.12",
+    "typescript": "^5.4.3"
+  },
+  "tap": {
+    "typecheck": true
+  },
+  "engines": {
+    "node": ">=16 || 14 >=14.18"
+  },
+  "funding": {
+    "url": "https://github.com/sponsors/isaacs"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/isaacs/path-scurry"
+  },
+  "dependencies": {
+    "lru-cache": "^10.2.0",
+    "minipass": "^5.0.0 || ^6.0.2 || ^7.0.0"
+  },
+  "tshy": {
+    "selfLink": false,
+    "exports": {
+      "./package.json": "./package.json",
+      ".": "./src/index.ts"
+    }
+  },
+  "types": "./dist/commonjs/index.d.ts"
+}