Skip to content

chore(deps): update dependency vitepress-sidebar to v1.40.0 - #62

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/vitepress-sidebar-1.x-lockfile
Open

chore(deps): update dependency vitepress-sidebar to v1.40.0#62
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/vitepress-sidebar-1.x-lockfile

Conversation

@renovate

@renovate renovate Bot commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
vitepress-sidebar (source) 1.39.01.40.0 age confidence

Release Notes

jooy2/vitepress-sidebar (vitepress-sidebar)

v1.40.0

Compare Source

  • A frontmatter field is now only read from the frontmatter block of a page. The reader fell back to scanning the whole file line by line whenever gray-matter returned nothing for a field, and never stopped at the closing delimiter, so a key: value line written anywhere in the content was read as if it were frontmatter. A page that documents a frontmatter — an order: 1 inside a fenced code block, or an exclude: true in an example — was mis-sorted, given the wrong title, or dropped from the sidebar entirely. The block is now the only thing scanned, and the fallback still applies when the frontmatter is not valid YAML. A field that is present is also used when its value is falsy, so order: 0 and exclude: false mean what they say instead of being treated as absent.
  • sortMenusByFileDatePrefix now sorts. It read the date prefix with split instead of match, which returns the part before the date and is therefore always the empty string, so every comparison was NaN and the items were left in the order the directory happened to be read in. That order is the one the file system returns, so it only looked like a date order on a file system that returns its entries sorted, and was arbitrary elsewhere. A menu item that does not begin with a date carries nothing to sort by, and is now kept together with the other such items before the dated ones, instead of leaving the whole level unordered.
  • documentRootPath and scanStartPath are now stripped from a link as the text they are, instead of as a regular expression. A ., a ( or a + in the name of a folder was read as a regular expression character, so a document root such as docs (v2) was left in every link and every menu item pointed at a page that does not exist. A scanStartPath is also read the same way whether or not it is written with a surrounding slash.
  • A folder is now skipped for being called node_modules or .vitepress only when that is its name. The check matched those names anywhere in the absolute path of an entry, so a project that merely sits somewhere below a directory whose name holds one of them, such as ~/my-node_modules-docs, produced an empty sidebar with nothing to explain it.
  • A prefixSeparator written as a regular expression no longer prints itself inside a menu title. A title holding more than one match was split and then re-joined with the regular expression, so a name such as 1.1.1-four-file became 11/\./1-four-file. The first match is now removed and nothing is re-joined, which is what the documentation describes. A match that does not open the title is also no longer moved to the front of it.
  • removePrefixAfterOrdering can be used on its own again. It reported 'prefixSeparator' should not use empty string unless a prefixSeparator was written down as well, because the check ran before the documented default of '.' was applied. Only a separator that is written down and empty is an error now.
  • sortMenusByFileCreateDate now reads the time a file was created instead of ctime, which is the last time the metadata of a file changed. A chmod, a rename or anything else that touched a file moved it to the end of the menu without its content having changed. A file system that records no creation time still falls back to ctime, which is the closest thing it has. Both this option and sortMenusByFileModifyDate also keep the time in milliseconds now, so two files written in the same second are ordered by which of them came first instead of being left in the order the directory was read in.
  • useTitleFromFileHeading no longer reads a # written inside a fenced code block as the heading of a page. A shell snippet whose first line is a comment, such as # Install the package, became the title of any page that showed one before its own heading. A block is only closed by a fence of the same character and at least the same length, so a block that holds another one is read as the one block it is.
  • withSidebar no longer writes to the VitePress configuration or to the sidebar options it is given. It replaced themeConfig.sidebar with an empty object, set debugPrint to false, and appended its dev-server plugin to the very vite.plugins array of the caller. VitePress evaluates its configuration again on every restart of the dev server, so that last one added the plugin once more each time. A configuration or an options object that is frozen, such as one written with as const, also no longer fails with Cannot assign to read only property.
  • A folder is now scanned in the order of its names, instead of the order the file system happens to hand its entries back in. That order is sorted on some file systems and a hash order on others, so a project with no sorting option built a different sidebar depending on the machine it was built on, and sortMenusByFileDatePrefix and sortMenusByFileCreateDate fell back to it whenever two items compared equal. The comparison is by code unit rather than by locale, so the same project always builds the same sidebar. The documentation already described this order; only now is it the one that is actually used.
  • A root group made by rootGroupLink or rootGroupCollapsed alone is now named Table of Contents, the default the documentation describes, instead of being left with no name at all. The default is only used where a root group is actually made, so a sidebar still gets one only when one of the rootGroup options asks for it.
  • sortFolderTo now reads a folder as a folder even when it holds no items. It told the two apart by the items of a menu item, which a folder kept by includeEmptyFolder, linked through useFolderLinkFromIndexFile, or emptied by excludeByFolderDepth does not have, so such a folder was moved to the end with the files.
  • Two sidebars that resolve to the same path are now reported. The second one replaced the first without a word, so a resolvePath written twice by mistake silently dropped a whole sidebar.
  • followSymlinks no longer fails the build on a symbolic link that leads back into the scan. A link pointing at a directory above itself was followed until the operating system stopped it with ELOOP, which ended the build. Every directory on the way to the current one is now remembered by the path it really is, so a link that closes the circle is left out instead. A link pointing at nothing is skipped as well, rather than stopping the build with ENOENT.
  • A documentRootPath or scanStartPath that does not exist is now reported by name, together with the working directory it was resolved from. The build used to stop at a bare ENOENT: scandir, which named neither the option that was wrong nor what it was resolved against.
  • The declaration files of the package no longer import ./types.ts. Three source files imported their types with a .ts extension, which survives into the declaration file, and lib is not published, so those files named something the package does not ship. Nothing reachable from the entry point pointed at one of them, so it broke no one yet; a test now keeps it that way.
  • Sorting no longer walks the items of a folder once for every level above it. The keys the sorting needs were removed from the whole subtree each time a level was sorted, which is work proportional to the depth of the tree for every item in it. Each level cleans up after itself instead. Alongside it, the type of a directory entry is now read together with the entry itself rather than looked up one statSync at a time, manualSortFileNameByPriority is read from a lookup instead of being searched per entry, the two collators are built once instead of once per folder, and looking for a dynamic route template stops at the first one found. Each of these is a small saving on its own; together they take a little off every build, and rather more off a deep tree, where the repeated walk cost the most.
  • A paths loader is now given two minutes to resolve its routes. It is project code run in a child process, and one that never returned held the whole build open. The sidebar is then built without the generated pages, as it already is for a loader that fails.
  • npm run build no longer reformats the sources it is about to build. It ran prettier --write first, which meant that prepare rewrote the working tree on every install, and that continuous integration silently repaired a formatting problem instead of reporting it. Formatting is checked by the new format:check script, which runs in continuous integration together with lint, neither of which was run there before.
  • Each Markdown file is now read and parsed once per build instead of once per option that reads something from it. useTitleFromFileHeading, useTitleFromFrontmatter, frontmatterTitleFieldName, excludeFilesByFrontmatterFieldName, sortMenusByFrontmatterOrder and sortMenusByFrontmatterDate used to read and parse the same file again each, up to four times over. On a 2,000 page project the combination of those options went from about 300 ms to about 100 ms, and frontmatterTitleFieldName no longer reads every file twice when the field it names is absent.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

Copilot AI lite review requested due to automatic review settings September 5, 2026 09:58

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot wasn't able to review any files in this pull request.


💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant