awesome-vue puts a generated table of contents in front of links that carry no dates

The repository is four entries and none of them can be installed

The whole project is a directory listing of four things: .github/, LICENSE, README.md and assets/. There is no source directory, no package manifest, no build step and no test suite, and the project has no GitHub releases at all.

That is the correct shape for a link index, and it is still worth stating plainly because it rules out most of what you might expect. You cannot add it as a dependency, you cannot consume it through an API, and you cannot pin a version of it. The entire value of the project is the text of one Markdown file, which means anything you want to do with it programmatically, such as loading these links into your own catalogue, means parsing that file yourself.

The absence of releases is the part that bites. A single mutable file on the master branch, last pushed on 2026-09-24, with no tag and no changelog, means there is no way to refer to a known state of the list. If two people disagree about what the list contains, there is no historical version to settle it.

The table of contents is generated by doctoc, the entries underneath are not checked by anything

A large share of the file is a table of contents that a tool maintains, fenced between two HTML comments:

<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RERUN doctoc TO UPDATE -->

The block runs to well over a hundred lines before the hand written entries begin. What that buys you is a consistent structure: every heading is in the index, nesting is correct, and the anchors resolve.

What it does not buy you is any check on the entries. doctoc confirms that a heading exists. It does not confirm that the link under it resolves, that the project is still maintained, or that the description is accurate. So the most maintained part of the file is its scaffolding and the least maintained part is its content, which is the opposite of what a reader assumes when they see a tidy generated index. The doubled word in the marker text is a small illustration of the same point: that block is written by a tool and nobody proofreads it.

Vue 2 and Vue 3 material sits in the same list with no version partitioning

Nothing on the page separates entries by Vue major version. Under External Resources there is a workshops link described as learning Vue 2 in the browser by building three applications, and a separate Vue 3 video playlist. Under Utilities, State Management is split into four sibling buckets: Mobx, Pinia, Authentication and Authorization, and Vuex Utilities.

So a Vue 2 tutorial and a Vue 3 playlist are filed as equals, and Pinia and the Vuex tooling are filed as equals, with no note about which one is current or which is legacy.

The consequence is that the list cannot answer the question most people arrive with, which is what to reach for in a new project. You cannot infer a target version from the section an entry sits in, so finding out means opening the destination and reading its own documentation. For state management in particular, the four-way split is the least helpful part of the taxonomy, because the two entries a newcomer actually compares are separated by two other headings and given equal billing with a state container and an auth helper. Partitioning by version, or annotating each entry, would fix a problem the list currently pushes onto the reader.

Truly awesome projects is three links whose bar is one sentence

Near the top of the Resources section there is a short list introduced by a single sentence setting the standard: these projects are exceptionally high quality, have a proven trackrecord, and are virtually indispensable. Three entries follow. Vue DevTools, a browser devtools extension for debugging Vue applications. unplugin-icons, an on demand icon loader supporting popular icon sets. And vue-i18n, an internationalization plugin for Vue.

It is a useful thirty seconds, because if you only install one thing this is where to look. It is also thinner than it looks. The criteria are stated once and are not measurable, and two of the three entries appear again further down the page in their own categories, since there is a dedicated i18n section under Utilities and icons belong under the UI utilities. So this is a pointer to three links rather than a separate judgement about them.

The consequence is that the part of the page most likely to be consulted on day one is hand maintained text sitting above an auto generated index, with no dates, and it inherits the same staleness risk as everything else here. If you install from it, check each project's own release history before you build on it.

Four separate Miscellaneous headings absorb whatever did not fit

The generated anchors expose the shape of the taxonomy. There are four headings named Miscellaneous, with the anchors miscellaneous, miscellaneous-1, miscellaneous-2 and miscellaneous-3, and they sit under four different parents: UI Components, the Form branch inside it, UI Utilities, and Utilities.

That is what a list looks like when it grows by addition rather than by design. Each new component that fits no existing category gets filed under a catch-all, and after a few years you have four of them, none labelled by content.

The consequence shows up the moment you search for something specific. If you are looking for a date picker, the list is genuinely good, because the Form branch names it. If you are looking for a marquee or a tour widget or a QR code component, the answer is somewhere in one of four buckets called Miscellaneous, and the heading tells you nothing about what is inside. There is also a second Form heading further down, under UI Utilities, holding only Validation, so even a name you can see appears twice with different contents. Browse the named categories first and treat the catch-alls as a last resort.

The Form branch is subdivided more finely than any other part of the list

One branch stands out for depth. Under UI Components, the Form category carries fifteen entries of its own: Phone Number Input Formatter, Picker, Generator with a nested Date Picker, Select, Drag and Drop, Type Select, Color Picker, Switch, Masked Input, Rich Text Editing, Image Manipulation, File Upload, Context Menu, Miscellaneous and Wizard.

Compare that with the flat siblings around it. UI Utilities holds seventeen single-level entries. Utilities holds about fifteen. Form is the only branch that goes three levels deep and the only one that separates a Picker from a Generator that then contains a Date Picker.

Read as curation, that is a signal about where demand has been: people kept asking for form widgets, so the list kept subdividing until it ran out of sensible splits. Read as a limitation, it means the deepest branch is also the least governed, because a hand built three level nest has no owner and no rule about what belongs where. A drag and drop library and a colour picker are peers here, which tells you the split is driven by what contributors happened to submit rather than by a taxonomy anyone agreed on.

Integrations are filed under Vue CLI plugins while the official resources point at Vite

The Integrations branch has a single path in it. Vue CLI Plugins contains exactly one entry, Google Analytics. That is the whole branch.

Set that against the Official Resources section at the top, which links the documentation, the API reference, the Vue core repository, the release notes, the style guide, the news feed, the IDE language support, and a link to Awesome Vite, the curated list for Vite. So the page's own official pointers lead you toward Vite while its plugin integrations are organised around Vue CLI.

The consequence is a dead end for anyone on a Vite based project. There is no build tool plugins section, no alternative location to look, and no note saying where these entries should go now. One analytics integration filed under a specific CLI plugin system is thin enough that the most likely explanation is that the branch stopped being maintained rather than that Vue has one plugin worth listing. If you are looking for build tooling, do not spend time in this branch, and read the destination of anything you do find there, because a Vue CLI plugin entry is not evidence that the project supports Vite.

No entry carries a date, and the file has never been tagged

There is no per entry date, no link checking policy described anywhere on the page, and no changelog. The only freshness signal available is the single commit date for the whole file, 2026-09-24, together with the fact that the repository is not archived.

One date for several hundred links is a weak signal by arithmetic. It tells you that somebody edited the file recently. It cannot tell you which entries were touched, which were left alone for years, or which destinations have stopped resolving since.

The consequence is that a link that rotted last spring is formatted exactly like one added last week, and nothing on the page helps you tell them apart before you click. This is the normal bargain of a hand curated index and the project is honest about being a curated list rather than a verified one, but the cost lands on whoever depends on it. If a link is going into something you are about to ship, open it, check the destination's own release history and issue activity, and treat this page as a starting point for where to look rather than as a recommendation.

Editorial conclusion

Use awesome-vue as a map of where the Vue ecosystem's parts live, and never as a source of truth about whether one of them is current. Take it when you want to know that a category of component exists and roughly which projects sit in it. Before you depend on any single entry, open the destination and check its own release date, because nothing in this repository dates its links, the file has never been tagged, and the whole file shares one commit date of 2026-09-24. If you are starting a new Vue project, resolve the version question yourself first: the list files Vue 2 workshops and Vue 3 material side by side, and it treats Pinia and Vuex utilities as equals, so it will not tell you which one the ecosystem expects now.

Frequently asked questions

Official sources

1. Official README
2. Project repository