feat: Phase 1 — extract the client (web SPA + desktop) to dtoro/oikos-web
Problem: the hexagonal refactor churns the backend tree for nine more phases; the UI delivery stack (web/ SPA, cmd/desktop Wails wrapper, compose/web image) must move to its own repo first so doc/layout rewrites land once on a backend-only tree. Change: - New repo git.hubris.network/dtoro/oikos-web (v0.33.0): web/, desktop/ (updateURL repointed to oikos-web releases), compose/, own CI (web + desktop jobs), own deploy script (CI-green gate, TOCTOU guard, version-tagged images, prune-to-3), own webhook receiver on :9798 + launchd unit, own compose project publishing the same 8091:80. - Cutover executed on mac-mini in order: oikos stack's web service stopped+removed, oikos-web project brought up on 8091; outer Caddy untouched (targets the published port) — serving + Authentik flow + /wails 404 quirk verified post-cutover. - Stripped from oikos: web/, cmd/desktop/, compose/web/, desktop CI workflow, ci.yml web job, Makefile ui/desktop/desktop-package/install targets, the compose web service, oikos-web from deploy.sh's fallback prune list; wails + go-keyring dropped from go.mod, vendor synced. - README / CONTRIBUTING / AGENTS.md / .agents dev+operations docs now point at the new repo; mbse + mascot design docs carry a path note. Risk: production SPA serving depends on the new pipeline now; rollback is versioned-image re-up of the old web service from a pre-split checkout (port 8091). Desktop builds installed before the split still check dtoro/oikos releases — one manual reinstall, noted in the oikos-web release notes. Verification: go vet, make test (race), make generate-check, golangci (no new findings; baseline down 400→365); post-cutover curls — localhost:8091 200, /wails/runtime.js 404, outer Caddy 302 Authentik.
This commit is contained in:
143
web/node_modules/graceful-fs/README.md
generated
vendored
Normal file
143
web/node_modules/graceful-fs/README.md
generated
vendored
Normal file
@@ -0,0 +1,143 @@
|
||||
# graceful-fs
|
||||
|
||||
graceful-fs functions as a drop-in replacement for the fs module,
|
||||
making various improvements.
|
||||
|
||||
The improvements are meant to normalize behavior across different
|
||||
platforms and environments, and to make filesystem access more
|
||||
resilient to errors.
|
||||
|
||||
## Improvements over [fs module](https://nodejs.org/api/fs.html)
|
||||
|
||||
* Queues up `open` and `readdir` calls, and retries them once
|
||||
something closes if there is an EMFILE error from too many file
|
||||
descriptors.
|
||||
* fixes `lchmod` for Node versions prior to 0.6.2.
|
||||
* implements `fs.lutimes` if possible. Otherwise it becomes a noop.
|
||||
* ignores `EINVAL` and `EPERM` errors in `chown`, `fchown` or
|
||||
`lchown` if the user isn't root.
|
||||
* makes `lchmod` and `lchown` become noops, if not available.
|
||||
* retries reading a file if `read` results in EAGAIN error.
|
||||
|
||||
On Windows, it retries renaming a file for up to one second if `EACCESS`
|
||||
or `EPERM` error occurs, likely because antivirus software has locked
|
||||
the directory.
|
||||
|
||||
## USAGE
|
||||
|
||||
```javascript
|
||||
// use just like fs
|
||||
var fs = require('graceful-fs')
|
||||
|
||||
// now go and do stuff with it...
|
||||
fs.readFile('some-file-or-whatever', (err, data) => {
|
||||
// Do stuff here.
|
||||
})
|
||||
```
|
||||
|
||||
## Sync methods
|
||||
|
||||
This module cannot intercept or handle `EMFILE` or `ENFILE` errors from sync
|
||||
methods. If you use sync methods which open file descriptors then you are
|
||||
responsible for dealing with any errors.
|
||||
|
||||
This is a known limitation, not a bug.
|
||||
|
||||
## Global Patching
|
||||
|
||||
If you want to patch the global fs module (or any other fs-like
|
||||
module) you can do this:
|
||||
|
||||
```javascript
|
||||
// Make sure to read the caveat below.
|
||||
var realFs = require('fs')
|
||||
var gracefulFs = require('graceful-fs')
|
||||
gracefulFs.gracefulify(realFs)
|
||||
```
|
||||
|
||||
This should only ever be done at the top-level application layer, in
|
||||
order to delay on EMFILE errors from any fs-using dependencies. You
|
||||
should **not** do this in a library, because it can cause unexpected
|
||||
delays in other parts of the program.
|
||||
|
||||
## Changes
|
||||
|
||||
This module is fairly stable at this point, and used by a lot of
|
||||
things. That being said, because it implements a subtle behavior
|
||||
change in a core part of the node API, even modest changes can be
|
||||
extremely breaking, and the versioning is thus biased towards
|
||||
bumping the major when in doubt.
|
||||
|
||||
The main change between major versions has been switching between
|
||||
providing a fully-patched `fs` module vs monkey-patching the node core
|
||||
builtin, and the approach by which a non-monkey-patched `fs` was
|
||||
created.
|
||||
|
||||
The goal is to trade `EMFILE` errors for slower fs operations. So, if
|
||||
you try to open a zillion files, rather than crashing, `open`
|
||||
operations will be queued up and wait for something else to `close`.
|
||||
|
||||
There are advantages to each approach. Monkey-patching the fs means
|
||||
that no `EMFILE` errors can possibly occur anywhere in your
|
||||
application, because everything is using the same core `fs` module,
|
||||
which is patched. However, it can also obviously cause undesirable
|
||||
side-effects, especially if the module is loaded multiple times.
|
||||
|
||||
Implementing a separate-but-identical patched `fs` module is more
|
||||
surgical (and doesn't run the risk of patching multiple times), but
|
||||
also imposes the challenge of keeping in sync with the core module.
|
||||
|
||||
The current approach loads the `fs` module, and then creates a
|
||||
lookalike object that has all the same methods, except a few that are
|
||||
patched. It is safe to use in all versions of Node from 0.8 through
|
||||
7.0.
|
||||
|
||||
### v4
|
||||
|
||||
* Do not monkey-patch the fs module. This module may now be used as a
|
||||
drop-in dep, and users can opt into monkey-patching the fs builtin
|
||||
if their app requires it.
|
||||
|
||||
### v3
|
||||
|
||||
* Monkey-patch fs, because the eval approach no longer works on recent
|
||||
node.
|
||||
* fixed possible type-error throw if rename fails on windows
|
||||
* verify that we *never* get EMFILE errors
|
||||
* Ignore ENOSYS from chmod/chown
|
||||
* clarify that graceful-fs must be used as a drop-in
|
||||
|
||||
### v2.1.0
|
||||
|
||||
* Use eval rather than monkey-patching fs.
|
||||
* readdir: Always sort the results
|
||||
* win32: requeue a file if error has an OK status
|
||||
|
||||
### v2.0
|
||||
|
||||
* A return to monkey patching
|
||||
* wrap process.cwd
|
||||
|
||||
### v1.1
|
||||
|
||||
* wrap readFile
|
||||
* Wrap fs.writeFile.
|
||||
* readdir protection
|
||||
* Don't clobber the fs builtin
|
||||
* Handle fs.read EAGAIN errors by trying again
|
||||
* Expose the curOpen counter
|
||||
* No-op lchown/lchmod if not implemented
|
||||
* fs.rename patch only for win32
|
||||
* Patch fs.rename to handle AV software on Windows
|
||||
* Close #4 Chown should not fail on einval or eperm if non-root
|
||||
* Fix isaacs/fstream#1 Only wrap fs one time
|
||||
* Fix #3 Start at 1024 max files, then back off on EMFILE
|
||||
* lutimes that doens't blow up on Linux
|
||||
* A full on-rewrite using a queue instead of just swallowing the EMFILE error
|
||||
* Wrap Read/Write streams as well
|
||||
|
||||
### 1.0
|
||||
|
||||
* Update engines for node 0.6
|
||||
* Be lstat-graceful on Windows
|
||||
* first
|
||||
Reference in New Issue
Block a user