build(deps): bump the napi group in /engine with 3 updates - #14
Closed
dependabot[bot] wants to merge 10 commits into
Closed
dependabot[bot] wants to merge 10 commits into
dependabot[bot] wants to merge 10 commits into
Conversation
Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 4.0.0 to 8.0.1. - [Release notes](https://github.com/actions/download-artifact/releases) - [Commits](actions/download-artifact@v4.0.0...v8.0.1) --- updated-dependencies: - dependency-name: actions/download-artifact dependency-version: 8.0.1 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4.0.0 to 7.0.1. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@v4.0.0...v7.0.1) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: 7.0.1 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [actions/cache](https://github.com/actions/cache) from 4.2.0 to 6.1.0. - [Release notes](https://github.com/actions/cache/releases) - [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md) - [Commits](actions/cache@v4.2.0...v6.1.0) --- updated-dependencies: - dependency-name: actions/cache dependency-version: 6.1.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
…g both ref fills `loadCommits` was the one read the engine lost: 12.9 ms against the CLI's 10.8 ms on a 1,036-commit repository, even though the engine call itself took 7.1 ms. The gap was two sequential `for-each-ref` spawns running after it (16.5d3/d5), putting back two fields the engine's types did not carry. Same defect as the repoInfo one fixed in 9fe6599, one layer down, so the same fix: teach the engine the field, delete the fill. `GitTagRef` and `GitCommitTag` gain `signed`. `refs.rs` reads it from the tag object it was already peeling, and records it on both records of an annotated tag, since the signature belongs to the tag rather than to either hash. `find_header` settles the object kind first, so a lightweight tag costs a header lookup, not a commit read. The semantics were checked against git rather than assumed: `%(contents:signature)` is non-empty only for a signed annotated tag object. A lightweight tag over a genuinely signed commit (`%G?` = `G`) reports unsigned, and the engine matches by construction. `read_remote_refs` now resolves symbolic refs instead of dropping them, which is what `%(objectname)` reports for the `refs/remotes/<remote>/HEAD` every clone writes. Verified on a clone carrying all four tag shapes and a symbolic origin/HEAD: engine and CLI ref labels identical with the engine serving the read, and the engine path down from 2 git spawns to 0 (the CLI uses 3). loadCommits 300: 11.5 ms CLI vs 7.7 ms engine, 0.8x -> 1.5x; view load 4.4x. Two tests pin it, each mutation-checked to kill only its own. The signed-tag fixture writes the tag object by hand, so CI needs no keyring. Also fixes a defaults drift found while answering why `initialLoadCommits` is 300: `loadMoreCommits` is 100 in the manifest and README but fell back to 75 in config.ts, with the test pinning the wrong value. It never fired in a real install, since VS Code returns the manifest default for an unset key. The 300 itself is left alone and documented as inherited from upstream — the git read and the graph layout do not justify it, but DOM row insertion was not measured and is the one cost that still could. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… at 300 The first page is the latency-critical one and stays at 300. The follow-on page goes from 100 to 1000, which is the better trade for how the table is actually rendered. `renderTable` builds one HTML string over every loaded commit and assigns it to `innerHTML`, so each "load more" rebuilds the whole table rather than appending to it. Reaching 3,000 commits therefore costs about 27 growing rebuilds at a step of 100 and about 3 at a step of 1,000 - a larger step is strictly less total work, not more. It also matters more than it looks, because `autoLoadMoreCommitsOnScroll` fires whenever the viewport comes within 96px of the bottom, so the small step stalls repeatedly during ordinary scrolling rather than only on a click. Measured through the webview harness, a full rebuild is 921 ms at 1,000 rows and 2,783 ms at 2,000. Those are jsdom figures and are not browser figures - jsdom parses HTML far more slowly and does no layout or paint - but they establish that the rebuild is at least linear in total rows with a constant that is not small. The engine-side read is negligible by comparison: 13.6 ms for 1,000 commits. The real fix is to append new rows instead of regenerating the table, making a page nearly free; that is a separate change to `renderTable` and is recorded in the knowledge base rather than attempted here. Manifest, accessor, README and the config test are set together, since that table mirrors the manifest by hand and had already drifted once. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Replaces the 300/1000 set in 9751c15 at the maintainer's direction. The reasoning there is unchanged - `renderTable` rebuilds the whole table on every load, so a larger step is strictly less total work, and `autoLoadMoreCommitsOnScroll` makes the small step stall repeatedly during ordinary scrolling - only the two numbers move. 250 trims the latency-critical first paint slightly. 750 keeps the follow-on page well clear of the old 100 while sitting below the 1,000 the render figures were taken at, which is the conservative direction given those figures are jsdom's and not a browser's. Manifest, accessor, README and the config test move together, since that table mirrors the manifest by hand and had already drifted once. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…'s escaping
Slice 16.7 declined `search_history` because the engine's search and this
project's search answer different questions: a regex over messages across
every ref, against a literal substring search plus author matching, hash
resolution, ref filters and a position for each hit. The decline was
right; the conclusion that search therefore stays on four `git`
processes was not. The engine gains `search_commits`, which reproduces
these semantics. `search_history` stays where it is, unused.
The CLI runs `--fixed-strings --grep`, `--author`, a hash lookup and one
unbounded walk that numbers every commit, then merges by that numbering.
The numbering is also a filter - a hit with no position is dropped, which
is why a hash resolving to an unreachable commit is not a result. The
engine does the same three matches in a single walk, which is where the
speed comes from: 62.0 ms -> 7.8 ms (7.9x) on a 1,036-commit repository.
Pinned at the boundaries the two would disagree on - eight parity cases
and twelve engine-side tests: a literal dot a regex would widen, a query
that is not valid regex, case folding, a body-only term `--grep` reaches
and `%s` does not show, an author-only match, an abbreviated hash, a hash
that resolves but is unreachable, and a `--glob=` pattern that still
declines to the CLI.
The parity table then failed on the CLI side, which is the point of
having one. `searchCommits` escaped its `--author` query with a
JavaScript-style `escapeRegExp`, but `--author` takes a *basic* regular
expression, where `\(` opens a group rather than escaping a parenthesis.
The escaping inverted the meaning, and since the four runs share a
`Promise.all`, any query containing an unbalanced `(` or `[` failed the
whole Find dialogue with `fatal: header, '\(': Unmatched ( or \(`.
`--fixed-strings` expresses the literal match that was always intended,
and still matches name and email substrings ignoring case - verified
against git before changing anything.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…pping regex Five exports whose consumers a permanent non-goal blocks forever, not merely functions nothing calls today. `search_history` was superseded by `search_commits` in the previous commit. `current_branch_name`, `current_branch_upstream`, `remote_names` and `load_commit_subject` are all read inside `kind: "action"` write flows, and "every write stays on `runGitRaw`" is the first entry in the permanent non-goals - so none of them had a reachable future. This is worth doing rather than leaving alone because a `#[napi]` function is an exported symbol, so it is a linker root and LTO cannot strip it: a dead export is genuinely carried in every shipped binary. `search_history` was also the only consumer of the `regex` crate, which goes with it. before 6,183,072 bytes after 4,814,416 bytes saving 1,368,656 (22.1%) per platform, ~10.4 MB across all eight Their `api::Engine` methods went too, along with the now-orphaned `GitHistoryMatch`, `SEARCH_LIMIT` and `collapse_whitespace`, and their tests. `Repo::remote_names` is a different function and stays - `graph.rs` needs it for `load_commits`. The bare-repository test keeps its object-read coverage and is renamed for what it now proves; the `Engine` smoke test reads the checked-out branch from `info.head`. TypeScript loses `currentBranchName`, which was declared on `EngineAddon` *and* in the `isEngineAddon` load-time guard - it could have rejected a good engine binary over a method nothing called. The 13 exports still unwired are kept and inventoried in the knowledge base with what each would serve, including `author_stats` and `activity_heatmap`, which the maintainer intends to wire for a Statistics tab. That slice has no CLI counterpart, so it is a deliberate exception to the two-backends-agree rule and is recorded as one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bumps the napi group in /engine with 3 updates: [napi](https://github.com/napi-rs/napi-rs), [napi-derive](https://github.com/napi-rs/napi-rs) and [napi-build](https://github.com/napi-rs/napi-rs). Updates `napi` from 3.12.2 to 3.13.0 - [Release notes](https://github.com/napi-rs/napi-rs/releases) - [Commits](napi-rs/napi-rs@napi-v3.12.2...napi-v3.13.0) Updates `napi-derive` from 3.6.3 to 3.6.9 - [Release notes](https://github.com/napi-rs/napi-rs/releases) - [Commits](napi-rs/napi-rs@napi-derive-v3.6.3...napi-derive-v3.6.9) Updates `napi-build` from 2.4.1 to 2.6.0 - [Release notes](https://github.com/napi-rs/napi-rs/releases) - [Commits](napi-rs/napi-rs@napi-build-v2.4.1...napi-build-v2.6.0) --- updated-dependencies: - dependency-name: napi dependency-version: 3.13.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: napi - dependency-name: napi-derive dependency-version: 3.6.9 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: napi - dependency-name: napi-build dependency-version: 2.6.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: napi ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Author
|
Looks like these dependencies are no longer updatable, so this is no longer needed. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the napi group in /engine with 3 updates: napi, napi-derive and napi-build.
Updates
napifrom 3.12.2 to 3.13.0Release notes
Sourced from napi's releases.
Commits
2763e12chore: release (#3538)5ae5cf6chore(release): publish0da138efeat(cli): self-sign OpenHarmony artifacts with --ohos-sign (#3539)2499a63feat(async-runtime): offer the MultiThread flavor on wasm32-wasip1-threads (#...886bd07chore(deps): update dependency oxc-parser to ^0.151.0 (#3542)edb0a29fix(napi): validate native payload provenance for External and instance data ...38162bbchore: release (#3529)ec3d8eafix(napi): guard AsyncTask completion against env teardown (#3536)96ed267chore(deps): update release-plz/action action to v0.5.139 (#3537)b2c9f3bchore(deps): update release-plz/action action to v0.5.138 (#3533)Updates
napi-derivefrom 3.6.3 to 3.6.9Release notes
Sourced from napi-derive's releases.
Commits
2763e12chore: release (#3538)5ae5cf6chore(release): publish0da138efeat(cli): self-sign OpenHarmony artifacts with --ohos-sign (#3539)2499a63feat(async-runtime): offer the MultiThread flavor on wasm32-wasip1-threads (#...886bd07chore(deps): update dependency oxc-parser to ^0.151.0 (#3542)edb0a29fix(napi): validate native payload provenance for External and instance data ...38162bbchore: release (#3529)ec3d8eafix(napi): guard AsyncTask completion against env teardown (#3536)96ed267chore(deps): update release-plz/action action to v0.5.139 (#3537)b2c9f3bchore(deps): update release-plz/action action to v0.5.138 (#3533)Updates
napi-buildfrom 2.4.1 to 2.6.0Release notes
Sourced from napi-build's releases.
Commits
a94cef3feat(napi): lock the allocator on threaded WASI and never hang after a worker...e50c819chore(deps): update dependency oxfmt to ^0.71.0 (#3549)29d4fa5ci: replace yarn with nodejs in msys2 pacboy install (#3553)afbe5dfchore(deps): update yarn to v4.18.1 (#3547)210bc27chore(deps): update dependency oxfmt to ^0.70.0 (#3543)2763e12chore: release (#3538)5ae5cf6chore(release): publish0da138efeat(cli): self-sign OpenHarmony artifacts with --ohos-sign (#3539)2499a63feat(async-runtime): offer the MultiThread flavor on wasm32-wasip1-threads (#...886bd07chore(deps): update dependency oxc-parser to ^0.151.0 (#3542)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions