You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scheduled dependency check against origin/master @ 61672aa (2026-10-05). Cross-checked every pin in nvim-pack-lock.json via git ls-remote + commit-range review; only genuinely new findings (not already covered by #327, #273, #271, #255, #154, #101, #138, #78) are below.
mini.nvim — breaking change upstream, pin not yet affected but worth planning for
Pinned 561751e (2026-09-22) vs upstream HEAD 65d615e (2026-10-04), 11 commits. Among them:
c0a9015 fix(ALL)!: remove compatibility code for outdated features — breaking (conventional-commit !). Message: "All new features were released fairly long ago with compatibility layer for previous behavior... hopefully everybody interested migrated as expected."
db75dd4 fix(surround): prepare to drop use_nvim_treesitter option
436b4fd fix(ai): prepare to drop use_nvim_treesitter option
This config's mini.ai.setup() / mini.surround.setup({...}) calls (lua/config/plugin_config.lua:15-40) don't set use_nvim_treesitter explicitly, so the current defaults aren't immediately broken by this range. But the ! commit removes back-compat shims outright, and the use_nvim_treesitter option is now explicitly slated for removal — worth a deliberate review (not a trivial bump) before next pulling mini.nvim past 65d615e. Not opening a PR for this one.
Corrections to existing open issues (ground-truth re-check)
blink.lib, sneaks.vim, guh.nvim, fugitive.vim (verified via github.com/tpope/vim-fugitive mirror since tpope.io is blocked from this environment), diffview.nvim, async.nvim, refactoring.nvim, conform.nvim, nvim-lint, tiny-inline-diagnostic.nvim, obsidian.nvim, render-markdown.nvim, plenary.nvim, snacks.nvim, noice.nvim, nui.nvim, fx.nvim, fff.nvim (within its 0.9.4 pin, already covered by #271) all have pinned rev == current upstream tip.
A separate, trivial-bump PR for fzf-lua + nvim-lspconfig (both additive/docs-only drift) was opened alongside this issue.
Scheduled dependency check against
origin/master@61672aa(2026-10-05). Cross-checked every pin innvim-pack-lock.jsonviagit ls-remote+ commit-range review; only genuinely new findings (not already covered by #327, #273, #271, #255, #154, #101, #138, #78) are below.mini.nvim — breaking change upstream, pin not yet affected but worth planning for
Pinned
561751e(2026-09-22) vs upstream HEAD65d615e(2026-10-04), 11 commits. Among them:c0a9015 fix(ALL)!: remove compatibility code for outdated features— breaking (conventional-commit!). Message: "All new features were released fairly long ago with compatibility layer for previous behavior... hopefully everybody interested migrated as expected."db75dd4 fix(surround): prepare to drop use_nvim_treesitter option436b4fd fix(ai): prepare to drop use_nvim_treesitter optionThis config's
mini.ai.setup()/mini.surround.setup({...})calls (lua/config/plugin_config.lua:15-40) don't setuse_nvim_treesitterexplicitly, so the current defaults aren't immediately broken by this range. But the!commit removes back-compat shims outright, and theuse_nvim_treesitteroption is now explicitly slated for removal — worth a deliberate review (not a trivial bump) before next pulling mini.nvim past65d615e. Not opening a PR for this one.Corrections to existing open issues (ground-truth re-check)
masterbranch — migrate tomain#101 (nvim-treesitter-textobjects pinned to frozenmaster): the repo's remoteHEADsymref now points atrefs/heads/main, and the current pinned rev (5c7b0263) is identical tomain's current tip. There is no drift and nothing to migrate —vim.pack's default-branch clone is already trackingmain, not the frozenmasterbranch. [deps] nvim-treesitter-textobjects pinned to frozenmasterbranch — migrate tomain#101's premise appears to no longer hold (same pattern as the stale [deps] nvim-treesitter repository archived (read-only since April 2026) — migration path needed #255 archival claim); worth a comment there rather than a new migration PR.4a6883c) isv1.5.1(also taggedstableupstream). Already current, nothing to bump.v2.1.0(a462f41, past thev2.0.0already flagged); our pin (070a5d7) is still pre-v1.0.0. No new action, just noting the gap has grown.vim.version.range("1.10.0")(a fully-qualified x.y.z string) produces an exact range (from == to == 1.10.0), matching whatnvim-pack-lock.jsonitself records ("version": "1.10.0 - 1.10.0"). This is a closed, single-version pin, not an open/unbounded one as [audit] fix: bound blink.cmp version range to stay off v2 #328 assumed — which is consistent with [audit] fix: bound blink.cmp version range to stay off v2 #328 having been closed without merging. The pin already fully blocks ablink.cmpv2 install; [deps] fff.nvim at 0.9.6 (config targets 0.9.4); blink.cmp v2 imminent with breaking config changes #271's recommendation to plan the eventual v2 migration still stands, just not as an urgent pin-safety gap. Side note: upstream has since released bugfix patchesv1.10.1/v1.10.2(both additive/bugfix per commit log, no breaking markers) that the exact pin excludes — low priority, mention only.Checked, no drift, no action
blink.lib,sneaks.vim,guh.nvim,fugitive.vim(verified viagithub.com/tpope/vim-fugitivemirror sincetpope.iois blocked from this environment),diffview.nvim,async.nvim,refactoring.nvim,conform.nvim,nvim-lint,tiny-inline-diagnostic.nvim,obsidian.nvim,render-markdown.nvim,plenary.nvim,snacks.nvim,noice.nvim,nui.nvim,fx.nvim,fff.nvim(within its 0.9.4 pin, already covered by #271) all have pinned rev == current upstream tip.A separate, trivial-bump PR for
fzf-lua+nvim-lspconfig(both additive/docs-only drift) was opened alongside this issue.🤖 Generated with Claude Code
https://claude.ai/code/session_019LFuDqrXyPqgBPwWcbd6Kr