Sweeps the build-time dependency tree, which is where most of what
`yarn audit` reports actually lives. This takes the frontend from 419
findings across 42 packages down to 16 across 9.
Most of it is lockfile-only. `yarn upgrade` does not re-resolve
transitive entries in yarn 1, so the affected entries were dropped from
yarn.lock and reinstalled, which picks the newest version each parent's
existing range already allows. That covers the four open dependabot PRs
(shell-quote, websocket-driver, @babel/core and
@babel/plugin-transform-modules-systemjs) along with @babel/helpers,
ajv, async, brace-expansion, form-data, glob, js-yaml, json5, nanoid,
terser and ws.
Re-resolving express to 4.22.2 pulls patched body-parser, cookie,
path-to-regexp and qs with it, and clears the stale minimatch 3.0.4 and
semver 7.0.0 pins at the same time.
browserslist and caniuse-lite had to move too. @babel/core 7.29 emits
'opera_mobile' as a compilation target and the pinned
@babel/helper-compilation-targets 7.17.7 rejects it, which broke the
production build until the whole toolchain was aligned.
storybook goes to 7.6.24 and webpack to 5.109.2, both direct
devDependencies pinned to vulnerable versions.
The `resolutions` additions are for packages whose parent pins a range
with no patched version in it. Each was verified against a build:
- svgo 2.8.3 removes the svgo 1.x subtree that @svgr/plugin-svgo drags
in. react-scripts sets `svgo: false`, so that plugin never runs, and
the production bundle is byte for byte identical with and without it.
- resolve-url-loader 5.0.0 is the only way to drop postcss 7. The
emitted CSS is unchanged, same content hash.
- @tootallnate/once, esbuild, nth-check, serialize-javascript, tar and
uuid are straightforward version forces.
What is left is either unfixable or would break the build:
- protoc-gen-js pulls got, http-cache-semantics, adm-zip and decompress
through the unmaintained `download` package. decompress has no
published fix. None of it runs outside `yarn protos`.
- webpack-dev-server 5 drops the onBeforeSetupMiddleware and
onAfterSetupMiddleware hooks that react-scripts 5.0.1 calls directly,
so forcing it would break `yarn start`.
- ip and lodash.pick have no patched version published.
- react-router needs v7, which is a separate migration.
Bumps the two production dependencies flagged by `yarn audit` that have
fixes available.
http-proxy-middleware goes to 2.0.10 for the Host-header routing bypass.
It also needs a `resolutions` entry, otherwise yarn keeps a second copy
at 2.0.9 under react-scripts > webpack-dev-server because the existing
`^2.0.0` range is already satisfied.
react-router-dom goes to 6.30.4 for the untrusted-path open redirect. It
is pinned exactly rather than with a caret: @remix-run/router is a direct
dependency at an exact version and react-router-dom pins its own copy
exactly too, so a caret here would let a future patch release install a
second copy of the router and hand <HistoryRouter> a history built by a
different module instance.
That bump pulls in a few related changes:
- react-router 6.4 folded the `history` package into @remix-run/router,
so the store now imports `createBrowserHistory` from there. Passing our
own history object is discouraged and would bundle history twice.
- @remix-run/router's type declarations use accessors in interfaces,
which needs TypeScript 4.3 or newer, so typescript goes to 4.9.5. TS
4.4 also began typing `catch` variables as `unknown`, so `handleError`
now takes `unknown` and narrows before reading `.message`, and the five
sites that read it directly narrow first as well.
- @types/history and @types/react-router-dom are v5-era leftovers that
now conflict with the types react-router-dom ships itself.
- The new history only accepts one active listener, but RouterStore and
<HistoryRouter> both need one, so RouterStore subscribes once and fans
updates out. It also needs `v5Compat` so listeners fire on push() and
replace() rather than only on back/forward.
reactour still pulls in a vulnerable lodash.pick with no patched version
published. reactour 1.18.0 is the end of the v1 line and v2 is a rewrite,
so that one is left alone for now.
Define the AccountPayments RPC endpoint and its request/response
messages in lit-accounts.proto. This endpoint allows querying
paginated payment history for a specific account.
Also update the frontend JS/TS proto sanitization script to map the
imported lnd.proto file to its flat directory path, fixing app build.
Bump `lnd` to version `v0.21.1-beta`, as well as `loop` to version
`v0.33.3-beta`. Additionally, we bump `looprpc` & `swapserverrpc` to
versions compatible with the new `loop` version.
Rewrite Loop's lnd proto import during proto generation so make protos
continues to work with this repo's local proto layout.
This became necessary when Loop v0.32.0-beta started shipping the
looprpc/client.proto change from upstream commit
f47b6115571f6072fe68057cb4eff30cc4fc47df
("looprpc: extend client.proto with lnrpc.OutPoint and
lnrpc.OpenChannelRequest"). That update made the downloaded Loop proto
import lnrpc/lightning.proto, while LiT stores the downloaded lnd proto
locally as proto/lnd.proto and invokes protoc with ../proto as the
import root. As a result, the downloaded Loop proto overwrote the local
compatibility fix and make protos failed with
"lnrpc/lightning.proto: File not found".
Patch the downloaded proto in build-protos.js to import lnd.proto
instead, and keep proto/loop.proto aligned with the same import path.
This is needed because changing only the checked-in proto file is not
enough: the build script re-fetches and replaces it on every run.
Run make rpc to regenerate JS/TS protobuf files for lnd v0.21.
The proto file drops the removed deprecated RPCs (SendPayment,
SendPaymentSync, SendToRoute, SendToRouteSync) and picks up new
messages and fields (onion messages, ChannelCommitUpdate,
walletSynced, graphCacheStatus, etc.). The frontend test sample data
is updated to include the new GetInfoResponse, WaitingCloseChannel,
and ChannelEventUpdate fields.
The `postbuild` script for the web UI invokes `git restore
build/.gitkeep` to bring back the placeholder file after
react-scripts wipes the build directory. When the repository is
checked out as a `git worktree`, the top-level `.git` is a file that
points at a worktree directory on the host. The dev.Dockerfile build
copies the working tree into the container with `COPY .`, but the
path referenced by that `.git` pointer is not part of the build
context, so any git invocation inside the container aborts with
`fatal: not a git repository`, causing `yarn build` and the whole
image build to fail.
Fall back to writing the `.gitkeep` content directly when
`git restore` is not usable. `git restore` is still preferred so that
the byte-for-byte contents from the index are used when git is
available; the fallback only kicks in when git cannot reach the
worktree, which is exactly the case inside the dev image build.
Bump `lnd` to v0.20.0-beta.rc2, `loop` to `v0.31.5-beta`, `tapd` to
`v0.7.0-rc2` and `lndclient` to `v0.20.0-3`.
Also bump `looprpc`, `swapserverrpc` and `taprpc` to the versions used
in the respective releases.
This commit also includes an update to the protos and sample data to
reflect the changes in the bumped dependencies.
Since we bumped the version of loop and lnd in the previous commit we
also caused the proto files to change. We need to regenerate the proto
files with `make protos` and commit them.
When running litd using a path-prefix (ex: PUBLIC_URL=/lit), the route
navigation was not working properly. It would navigate to `/connect`
instead of `/lit/connect`. The fix was simply to ensure the new route
was always prefixed with the `PUBLIC_URL` env var.
Add the `commit_hash` field to the GetInfoResponse. The `commit_hash`
field will contain the most recent commit_hash that the build was based
on. If the build had uncommitted changes, this field will contain the
most recent commit hash, suffixed by "-dirty".
The semantics of the `version` field is also updated to always contain
the most recent semantic version of the litd node, following the
semantic versioning 2.0.0 spec (http://semver.org/).
This commit introduces the structure for new endpoints in the accounts
subsystem, enabling balance adjustments by crediting or debiting a
specified amount. This contrasts with the existing `UpdateAccount`
implementation, which directly sets the balance to a fixed value.
For more details on the drawbacks of the current implementation, see
[issue #648](https://github.com/lightninglabs/lightning-terminal/issues/648).
The actual implementation of the endpoints will be introduced in
subsequent commits.
